simoncozens
commented
4 years ago OK, I see the need for this in terms of packaging, but there's another need, which is to be clear on which patches have been merged from upstream (TeX live) and which haven't. I've just done a git svn rebase in addition to the usual git svn fetch and realised we have a few years worth of patches to merge...
The TeX Live project is versioned on year of release; within that, they "release" versions by changing the version number in configure.ac. I don't really want to impose semver on this because it doesn't really track with anything on the TeX side, but I can see the appeal of it.
One thing we need to track, regardless of version number, is the current SVN commit number of the upstream. (i.e., we are now at version 37180 but we really should be at version 53691).
Perhaps the answer would be to version it according to TeXlive release year. What do you think?
alerque
@simoncozens What's your thoughts on a versioning scheme for this project? Is there anything on the TeX side we need to match? Can we stick to semver? If so can we extrapolate what the current version is based on any significant history points (breaking changes for the major, perhaps matched to sile release versions for the minor) and at least tag the current release and maybe back-fill tags for any previous releases?
I'm running into more packaging systems where it would be useful to build and install this separately from SILE. Void Linux already extracts it into a separate package but doesn't have a way to identify the versions. Arch Linux currently is bundling it but writing to a shared destination, which will keep it from ever getting accepted into the community package set (currently it is in the AUR which is one step removed).