Tag releases

[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).

[simoncozens]

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]

Yes, if this is tracking upstream changes, then we should version accordingly.

By the way we don't want to rebase this code, we would want to merge / cherry pick stuff from upstream.

How about using the TeXLive year + svn number + our own counter? For example 2019.53691.6?

[simoncozens]

No, I don't merge TeX Live into libtexpdf; what I do is a horrible two-step dance, but I think it's necessary:

• Pull down TeX Live's SVN repo into a git-svn repository.
• Cherry-pick / split patches from that into another git repo which contains both the libtexpdf code and the dvipdfm-x utilities.
• Split out the libtexpdf part.

I like the year + svn + own counter suggestion. That allows us to easily track what's going on upstream, and also any changes that we have introduced (such as the Win32 stuff).