ad-freiburg
Publish a change log and semver tags
For a relatively popular project that is likely to grow rapidly in near future, it should be very important to start maintaining a changelog and tag the repository/docker images using semantic versioning.
Presently, it is awkward to pin to a specific version of qlever. Automatic SHA256 checksums need are required in lieu of tags.
More importantly though, consumers have no sense of whether updating to a newer version poses any risks of breaking changes, nor what new features and fixes are delivered.
Tagging releases and linking each to the list of changes should be a priority. You could start from an arbitrary 0.x version of some 1.0 prerelease such as 1.0-beta ot 1.0-RC if you think you're close enough, although the latter precludes you from introducing breaking changes until you got to 2.0. On the other hand, "minor" version bump is considered a breaking release while in the 0.x release cycle
BTW there is qlever --version. It currently reports 0.5.x. Not sure where this is coming from & I don't see it exposed anywhere else, including git tags at the moment.
@tpluscode I completely agree, the problem is that we have several things that are of the highest priority at the moment and we have to prioritize among these :-)
Until the end of June, we are super busy with achieving full SPARQL 1.1 conformance, making update operations more efficient, making the dynamic spatial joins more efficient, extensive benchmarking, and providing a Wikidata endpoint that is in sync with the official endpoint via the new update stream.
I consider it likely that we can address the important issue of releases in July. In particular, this will require bundling together the various tools (backend, command-line tool, ui, petrimaps, ...). Not super hard, but a significant amount of work and we want to do it right.
Well, IMO it's something that should have been done long ago.
And given important work being done to the engine itself, it is that much more important to actually document the changes to the benefit of your consumers.
I agree that choosing the right tooling and building some automation will require some effort. A modest first step could be to at least start maintaining a handcrafted CHANGELOG.md to list changes.
And start tagging the repo+images.
@tpluscode We put a lot of care into pull requests of a meaningful size and with very good descriptions, so git log actually provides a very good change log, and considering each commit as a release is not a bad approximation. Indeed, we automatically build docker images for each commit.
Any update on this? I notice that I'm reluctant to test and play with Qlever since I have no clue which version I am using
This is how I do the version check:
∴ docker run --pull always -i -t --rm --entrypoint bash adfreiburg/qlever:latest -c "qlever --version"
latest: Pulling from adfreiburg/qlever
Digest: sha256:60c62c4f77cea7d49110de797df74a060fb6c760cd92c5ccaeac8fed40aae924
Status: Image is up to date for adfreiburg/qlever:latest
qlever 0.5.29
Related:
- https://github.com/ad-freiburg/qlever/issues/2466
- https://github.com/ad-freiburg/qlever/issues/2467
You are all absolutely right, we should do this as soon as possible. Popularity can be a bitch because there are so many things right now that we should do as soon as possible. Please have a little more patience, it will come
Wait, so qlever does have a semantic version!
Is it accurately representing breaking changes?
For starters, maybe it is a low hanging fruit to use that version for image tags?