Git package versioning: the "rREVISION" part

nbd · 2015-07-11 15:10:43

Wiki recommends the following:

It is recommended to have following version format: RELEASE.rREVISION where REVISION is a monotonically increasing number that uniquely identifies the source tree (VCS revisions do this).

It's my understanding, that according to this recommendation the rREVISION number monotonically increases across ALL releases, not being reset to 1 with each release. I.e.:

1.0.r1
1.1.r2
2.0.r3
2.1.r4
etc...

But according to bash oneliners in the same wiki the rREVISION number is the number of revisions of a particular release and resets to 1 with each release:

git describe --long | sed 's/\([^-]*-g\)/r\1/;s/-/./g'

What rREVISION number should describe and is it really important if the official recommendations are so vague?

Scimmia · 2015-07-11 15:14:30

It's important that each commit is seen as an upgrade, that's all.

anatolik · 2015-07-11 20:43:45

nbd wrote:

It's my understanding, that according to this recommendation the rREVISION number monotonically increases across ALL releases

Pacman deals with whole version and does not care if it has git revision or something like this. The requirement that whole version monotonically increases.

REVISION that starts from the very beginning of the history (like what you suggest) also matches requirement of monotonically growth and can be used as well. SVN vcs packages do this but the reason is that svn does not have an easy way to count revisions number from the last tag. Git has such possibility. And starting git revision count from the last commit makes package version more readable. It show how far the source tree went from the last release.

nbd · 2015-07-11 22:47:39

Thanks for your answers. How it follows from the Wiki, the single sequence of rREVISION across all releases is needed in case if the program's version numbering scheme is changed: if rREVISION is present, it is used for determinig wich version is older. So if one intends to stick, say, to '1.2.3' scheme, then I guess it's OK not to use rREVISION at all (if the third number is used as the revision number of two-numbers version), or to limit it to revisions of a particular release.

Trilby · 2015-07-11 23:11:48

nbd wrote:

if rREVISION is present, it is used for determinig wich version is older.

Not by pacman it isn't. If someone screws up the major version number such that a new release has a lower number, pacman will register it as a downgrade. (unless ... see end of this post)

nbd wrote:

... if the program's version numbering scheme is changed

That should be avoided. But if it absolutely can't be avoided, an epoch number should be used - this is explained in the PKGBUILD wiki for the very case you describe of the upstream version numbering scheme changing.

nbd · 2015-07-12 01:31:42

Trilby wrote:

Not by pacman it isn't. If someone screws up the major version number such that a new release has a lower number, pacman will register it as a downgrade. (unless ... see end of this post)

Thanks for clarifying. Below quote from Wiki is slightly unclear on this topic:

This delimiter allows to avoid problems in case if upstream decides to make its first release or uses versions with different number of components. E.g. if at revision "455" upstream decides to release version 0.1 then the revision delimiter preserves version monotonicity - 0.1.r456 > r454. Without the delimiter monotonicity fails - 0.1.456 < 454.
https://wiki.archlinux.org/index.php/VC … guidelines

Arch Linux

#1 2015-07-11 15:10:43

Git package versioning: the "rREVISION" part

#2 2015-07-11 15:14:30

Re: Git package versioning: the "rREVISION" part

#3 2015-07-11 20:43:45

Re: Git package versioning: the "rREVISION" part

#4 2015-07-11 22:47:39

Re: Git package versioning: the "rREVISION" part

#5 2015-07-11 23:11:48

Re: Git package versioning: the "rREVISION" part

#6 2015-07-12 01:31:42

Re: Git package versioning: the "rREVISION" part

Board footer