[Kolab-devel] Closing Call for KEP #5: Product Versioning

[Christoph Wickert]

Am Dienstag, 1. März 2011, 11:40:51 schrieb Jeroen van Meeuwen (Kolab 
Systems):
> Hello,
> 
> KEP #5: "Product Versioning" has been under review for an extensive period
> of time now.
> 
> Given the lack of objections to or improvements of the process enhancement
> proposal, this proposal now enters Closing Call.

Hi Jeroen,

thanks once again for working on this. While I was working on Kolab 2.3, I 
figured how well thought out your proposal is. However I have a few additions 
and concerns that I already outlined in a previous mail [1]. I'm sorry to 
speak up so late but AFAIR your feedback to my mail was (relatively) positive.

> http://wiki.kolab.org/index.php?title=User:Kanarip/Draft:KEP:5&oldid=11054

Let's go through this document one by one:

Abstract: no additions, concerns whatsoever, ok

Major, Minor and Teeny: ok

The Major Version Component: ok

The Minor Version Component: ok

The Teeny Version Component:
I'm having problems with the first sentence "The Teeny Version SHALL only be 
bumped for bug-fix releases." I think we need a MUST here instead of SHALL.

Rationale: If I understand correctly, this KEP applies to both to the overall  
Kolab server as well as to it's individual packages. Currently we have 
packages that get recompiled against newer dependencies and still have the 
same name-version-release, so the package name is exactly the same and there 
is no way to distinguish the new package from the old. I consider this one of 
the biggest problems with our OpenPKG packages and we must make sure that we 
fix it. This being said we MUST increase the teeny version for both packages 
as well as for the overall Kolab solution.

Whether or not updates of individual packages also require increasing the 
teeny version of the complete Kolab server is subject of further discussion.

Release: ok

Exceptions for Unstable Bug-fix Releases:
I don't see any benefit in x.y.z-rc1, it forces us to introduce a 4 digit 
versioning for the final release. If we have an update to rc1, that is not rc2 
either, we should rather rc1.1.

Releases and Native Packaging: ok

Pre-Releases and Native Packaging:
On the rpm side your versioning is broken and I'm not sure if it works with 
with deb either. We should follow the logic of the tools and use the 
versioning guidelines of the distributions to avoid these kind or problems.

RPM:
The example you give does not work:
$ rpmdev-vercmp kolabd-2.3-0.4.rc1.el5 kolabd-2.3.0-1.el5
0:kolabd-2.3-0.4.rc1.el5 is newer

For rpm we cannot omit the trailing 0 for pre-releases!
$ rpmdev-vercmp kolabd-2.3.0-0.4.rc1.el5 kolabd-2.3.0-1.el5
0:kolabd-2.3.0-1.el5 is newer

Deb:
While rpm compares sorts verioned (like sort -V), apt/dpkg first *only* 
compare the digits numerically (sort -g) and if they match, do a lexical 
comparision of all ASCII characters where the following characters are allowed 
in the release: + . ~
Sorting is done from ~ over . to +, this means ~ is used for pre-releases, 
while + is used for post-release packages and . of course for the 'normal' 
releases.
Numerical sorting also means that just like with rpm we cannot omit the 
trailing 0 in the version, although for a different reason. This makes me 
wonder if we should also use keep the trailing 0 in the tarball releases for 
constancy.

Bringing this together we have the following

RPM                           vs. DEB:
kolabd-2.3-0.1.beta1              kolabd-2.3.0-~1.beta1
kolabd-2.3-0.2.beta1              kolabd-2.3.0-~2.beta1
kolabd-2.3-0.3.beta2              kolabd-2.3.0-~3.beta2
kolabd-2.3-0.4.rc1                kolabd-2.3.0-~4.rc1
kolabd-2.3.0-1                    kolabd-2.3.0-1
kolabd-2.3.0-2.2011git0392jkljs   kolabd-2.3.0-2.2011git0392jkljs

Basically we just interchange a 0 with ~, I think this level of differnce 
should be ok. I *think* the versioning I listed for rpm *should* also work for 
deb, but there might be some corner cases we don't cover. As the sorting 
algorithms are fundamentally different I strongly propose to stick with the 
individual tools rather than applying the same logic to both.

Regards,
Christoph


[1] http://kolab.org/pipermail/kolab-devel/2010-November/012545.html
[2] http://www.debian.org/doc/debian-policy/ch-binary.html#s-versions
[3] http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Version

-- 
Christoph Wickert
Senior Engineer

Kolab Systems AG
Zürich, Switzerland

e: wickert at kolabsys.com
t: +49 251 871 369 77
w: http://kolabsys.com

pgp: 85DACC63 Christoph Wickert
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.kolab.org/pipermail/devel/attachments/20110314/1bb9e040/attachment.sig>