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

[Jeroen van Meeuwen (Kolab Systems)]

Christoph Wickert wrote:
> Hi Jeroen,
> 

Hi Christoph,

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

While SHALL is intended to have the same meaning as MUST[1], I see what you 
mean. Yet though any other phrasing gets in the way of allowing a Minor bump 
with just bug-fixes and no (feature) enhancements.

[1] http://www.apps.ietf.org/rfc/rfc2119.html

> Rationale: If I understand correctly, this KEP applies to both to the
> overall Kolab server as well as to it's individual packages.

Yes, as far as those packages are related to the server release, indeed that 
is the case.

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

I think this concern goes to package release -with regards to the package 
NEVRA- more so then the version component of the upstream product, correct?

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

I think not; the update of a component (say, perl-Kolab) does not *require* 
the entire Kolab OpenPKG stack to be released and its version number to be 
incremented.

That said, however, OpenPKG is the limiting factor as it virtually requires a 
version number to be incremented should one component be updated - at least 
the way we distribute the OpenPKG releases prohibits components to be updated 
without releasing the entire stack.

I think this should not hold back the updates for various components we are 
upstream for, or that we provide through our repositories, in light of and 
with help from the native packaging effort; here we can release a single 
update for a single component quite easily.

As various components are being updated and these updates are being released, 
at some point this may justify an updated OpenPKG stack to be released -with 
an incremented version number.

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

The exception applies to the following scenario, and perhaps the KEP deserves 
some extra verbosity:

- Foo version 2.5.3 has been released.
- Foo version 2.5.4 is being developed, and while only bug-fixes are being 
incorporated, a sneak preview for the upcoming release of 2.5.4 may be 
warranted to allow testing of a bug-fix that touched critical code.

You see while the general rule for pre-releases applies to pre-releases for 
Minor development cycles (e.g. 2.5-alpha1 vs. 2.5.0 -final), the exception 
applies to pre-releases for Teeny versions.

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

Aye, the example should have been:

$ rpmdev-vercmp 0 2.3 0.4.rc1.el5 0 2.3.0 1.el5

for (from --help):

rpmdev-vercmp <epoch1> <ver1> <release1> <epoch2> <ver2> <release2>

The same goes for APT, where 2.3 < 2.3.0, regardless of the release (but with 
the same "epoch", of course).

Kind regards,

Jeroen van Meeuwen

-- 
Senior Engineer, Kolab Systems AG

e: vanmeeuwen at kolabsys.com
t: +316 42 801 403
w: http://www.kolabsys.com

pgp: 9342 BF08
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kolab.org/pipermail/devel/attachments/20110314/f3039242/attachment.html>