Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tag releases #15

Open
alerque opened this issue Feb 6, 2020 · 3 comments
Open

Tag releases #15

alerque opened this issue Feb 6, 2020 · 3 comments
Assignees

Comments

@alerque
Copy link
Member

alerque commented Feb 6, 2020

@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
Copy link
Member

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
Copy link
Member Author

alerque commented Feb 6, 2020

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
Copy link
Member

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants