Re: Epoch version for golang-github-gomodule-redigo-dev?
Paul Gevers wrote:
> > 1) use 2.0.0+really1.8.3 pattern for our Debian package version
> As it seems not unreasonable to expect the upstream version to go past
> 2.0.0 in the not infinite future, this is the approach I would take.
The +really pattern is normally used when the version in Debian needs
to be reverted, such as src:capstone in unstable and src:lxc in buster.
In these cases, upstream's versioning scheme didn't change: the only thing
that actually changed was Debian's idea of which upstream version was
(temporarily!) most suitable for testing/unstable, and that is something
that can eventually go away when that upstream version is superseded by
one that is "even better".
The move of src:acme-tiny from 20171115-2 to 1:4.0.4-1 [1] is a clearer
example of the upstream versioning scheme genuinely changing, which is
the situation that epochs were originally designed for.
[1] https://lists.debian.org/debian-devel/2019/04/msg00052.html
golang-github-gomodule-redigo-dev seems to be somewhere between those
situations: upstream have not changed how their versioning scheme works,
but they are no longer releasing versions 2.x and want people to use
versions 1.x instead, for reasons that I don't fully understand.
If old-1.x is incompatible with 2.x, and new-1.x is considered to be
"better than" 2.x but is incompatible with 2.x, while old-1.x is compatible
with new-1.x (in other words, there were incompatible changes in 2.x but
the upstream project now considers them to have been a mistake and has
reverted them), and the upstream project intends to be using semantic
versioning, then I think the cleanest representation would be for the
upstream project to bump the version to 3.x and move on. (Justification:
semantic versioning says you bump major version on incompatible changes,
and the releases that are considered to supersede 2.x are incompatible
with 2.x, so they should maybe be 3.x.)
However, if they won't do that, and they upstream consider 2.x to be
a dead end and have resumed releasing 1.x, then it's not necessarily
the case that there will ever be another 2.x or higher version; so the
advantage of +really (that you can eventually discard it) might never
actually materialize. So an epoch might be more appropriate here than
it would initially seem.
smcv
Reply to: