Semantic Versioning & Import Fixes to Previous Versions about sparql-client HOT 5 CLOSED

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.

from sparql-client.

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 0338c80)

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?

from sparql-client.

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.

from sparql-client.

Pushed 1.99.1, 2.0.2 and 2.1.0.

from sparql-client.

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

from sparql-client.