Proposal: semantic versioning and release overview
sloede opened this issue · comments
For us as downstream maintainers of P4est.jl/P4est_jll.jl or t8code_jll.jl, it would be very helpful if p4est releases always used semantic versioning for its releases. That is, each release should be assigned a version number in the form of X.Y.Z, where Z is increased for patch releases, Y for feature upgrades, and X if there are backwards-incompatible changes.
It would also be super helpful if there were an overview of what the current release is and what previous releases were. This could be either documented on a website, README, or by using the GitHub feature to create a release from a tagged version. At the moment, the only way to check the current release is by going to http://p4est.org/ and checking the version on the filename of the latest release tarball.
Currently, the current release seems to be 2.8.5.5-9ddbb. However, before that it seems that p4est already adhered to semantic versioning (although there seem to be two development paths, v2.8 and v2.3). It would be great if the previous practice would be picked up again, since it makes it easier for us to, e.g., create corresponding releases for Julia. I know this sounds like a fussy request, but it would really make life a little easier 🙂
Relevant are the first three numbers, in this case 2.8.5. Everything after that has no semantic meaning. I'm looking forward to releasing 2.8.6 soon, with updates mostly to the build system (thanks to the community!).
We take care, carefully (but only recently), of the API version in the sense of libtool, which is not necessarily identical to the release version: https://www.gnu.org/software/libtool/manual/libtool.html#Versioning
It's a good point to maintain release notes, I agree and we should be putting them together more formally.
I'm not a fan of accepting github as release authority, so the versioning and tagging will remain manual.
I'm looking forward to releasing 2.8.6 soon
That sounds great!
It's a good point to maintain release notes, I agree and we should be putting them together more formally.
If this were possible, it would be awesome as well! However, I know from personal experience that this puts additional burden on the maintainers and thus is sometimes pushed back in the list of priorities, or until figured out what exactly should go into such a list, where to store it etc.
A smaller change that would already help us is if there were simply a list (e.g. in a file such as releases.md) that gets updated with the date and version of a new release, sorted from newest to oldest. This way, a downstream maintainer can just have a look at this list to know if a new release has been created and when.
I'm closing this issue since its original aim has been achieved. Thanks @cburstedde for being so responsive and understanding 🙏