Semantic Versioning & Import Fixes to Previous Versions

[cecton]

Hello,

This issue is probably not related to you directly but I believe it can brings something good to this project. So please take it as a proposal of improvement for this project.

Here is my proposal:

I may be wrong but your version format looks like semantic versioning. Therefore it would be nice if you maintain a branch my MAJOR.MINOR.x version (1.99.x, 2.0.x, etc...). Every fixes should cherry-picked on every branch. And from time to time, you release a fixed version of the branch by tagging a commit in the specific branch with all the fixes and increasing the x value.

Which basically means that the fixes that got merged in the develop branch can be merged to 1.99.x and 2.0.x and can fix already released versions. (If they are considered as "fixes" (this can be argued)).

Why am I proposing this?

So the question is... cui bono? :grinning: Well... _me_ in the first place because the maintainers of the public repository I'm currently "fixing" are reluctant to merge my PR because it's close to dirty monkey patching. Which is totally true :smile:

So, there aren't many solutions:

• we merge my PR that monkey patch
• we make a fork of sparql-client with all the fixes (despite they're going to be available at some point)
• we make sparql-client follows the semantic version and all future version of sparql-client will benefit of fixes made later on (which is cool!)
• I fork the mu-ruby-template template to a private repository for my company and have the fix available (may include more work on my side :unamused: )

So what do you think?

In brief:

• make 1.99.x branch
• make 2.0.x branch
• cherry-pick fixes and later fixes to every branch
• set up CI to test every branch
• tag once a while every maintained branch

(And I can help)

Thanks for taking time to read this

Additional info: a colleague just pointed out that the rubygems.org recommends the semantic versioning: http://guides.rubygems.org/patterns/#semantic-versioning

[gkellogg]

We do use semantic versioning, and all releases are tagged so that patches can be released in the future. However, given limited resources, we do not back port all bug fixes to previous releases, unless a specific request is made – ideally in the form of a patch-request. (You'll note the 1.1-support branch, and we can easily create new branches on demand).

I've created a 1.99-support branch, and updated a number of commits from the master and develop branches that are compatible. If you'd like, you can submit PR requests on the branch.

There are minimal changes from 2.0 to 2.1 – it is mostly a change due to minimum-ruby requirements. If you would like this branch created and maintained too, let me know.

[cecton]

Thank you very much, it would be great!

Actually we have a dependency on linkeddata=2.0.0 which seems to include a sparql-client=2.0.1 but there is no tag for it here (I suppose it should be on 0338c808c70119fe90526e6d1602c94da6e883fa)

What I would like is to have a sparql-client=2.0.2 with the latest commit of develop (it looks stable and it seems to only contains fixes). And have linkeddata=2.0.0 using sparql-client=2.0.2.

Does that make sense?

[gkellogg]

There was no 2.0.1 release, but I can release it based on the current state of develop, which should bring it in line with the 1.99 support branch, and release 1.99.1 as well.

Note that linkeddata uses '~> 2.0', which is compatible with 2.0.1, but also, a future 2.1.0. I'll release 2.1.0 with the Ruby version changes.

[gkellogg]

Pushed 1.99.1, 2.0.2 and 2.1.0.

[cecton]

@gkellogg I would like to thank you again for the very good support on this library. Everything is perfectly working on our side now.