Richard W.M. Jones wrote:
This package just numbers their tarballs using the subversion
number. For example, 'r8' and 'r11':
As far as I'm aware they are not planning on using "real" version
numbers at any time in the future, nor have they used real version
numbers in the past.
Note that the crux of this statement is "at any time in the future".
upstream dies and then is revitalized later and the new project lead
starts releasing tarballs, you could need epoch to get out of the
versioning scheme you choose. (However, epoch does exist, so it's not
like you can't escape).
I don't understand which if any of these guidelines apply to
In particular, what should the Version be? (And while we're at it,
what should the Release be?)
In my personal descending order of preference I would do one of these:
The first, second, and fourth are reasonably safe in case a new upstream
emerges at some point in the future and decides to make releases with
version numbers. The third would need an epoch if that were to occur.
The first and second will survive if upstream switches to a new version
control system which doesn't have release numbers (for instance, git and
starts using dates) or has different release numbers (ie, starting over
from 1) while the other two could require changes.
The first and second most closely follow the letter of our guidelines
(non-numeric version and snapshot package respectively) so they will be
least confusing if you get a reviewer who thinks that's important and
also will help any packager who takes over from you not make silly
mistakes if they don't understand the limitations of the other forms.
The first doesn't make you figure out the date which is irrelevant since
you're pulling from a released tarball.
The fourth, while closest to what upstream has, includes an alpha
character in the version which is something that is explicitly forbidden
in the Packaging Guidelines. If you want to use that, we'll need to
vote on an amendment to allow it.