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

[Christoph Wickert]

Hi Jeroen,

sorry, to respond so late. I know I have missed the bus but Georg asked me if 
everything is ok from my side.

Basically I'm ok with everything you write in your latest mail, but what about 
the parts of my mail you did not respond to?

Am Montag, 14. März 2011, 14:09:06 schrieb 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

Ok, understood.

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

Yes, but the KEP also covers packaging, right?

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

Ok

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

Ok, but this is not clear with the current wording. Not sure if we need to 
spend ime on this as the example you give is very unlikely to happen.

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

Indeed, i used rpmvercomp incorrectly. Sorry about that. 

But what about the things I mentioned in my previuos mail and that you trimmed 
in your response. They are more important to me than the question whether we 
have one digit more or less.

Basically it comes down to: Do we want to apply a versioning scheme that was 
developed for rpm to deb as well?

Pro:
Packages will always have the same NVR, regardless of the plarform.

Con:
Does not follow Debian guidelines.
Does not follow the logic of the tools.
Might clash with other native packages that were not packaged by us.
Users who have a Debian background will find this versioning confusing.

I have no intentions to delay this KEP any further but I think we should 
discuss this question unbiased.

Regards,
Christoph
-- 
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/20110330/1514c24a/attachment.sig>