[Kolab-devel] KEP Draft: Product Versioning

[Jeroen van Meeuwen (Kolab Systems)]

On Wednesday, November 24, 2010 02:21:45 am Christoph Wickert wrote:
> On Friday 19 November 2010 01:43:48 Jeroen van Meeuwen (Kolab Systems) 
wrote:
> > I wanted to document the 'criteria' or 'guidelines' we use for product
> > versioning for Kolab Groupware, to both form consensus and provide some
> > clarity, so that we may be consistent and transparent in the future
> > -largely benefiting our admin users, I hope.
> > 
> > Before we attach a number to it, though, I wanted to quickly poll for any
> > early feedback.
> 
> Hi Jeroen,
> 
> most things look sane. The major.minor.teeny versioning scheme is well
> established, however I have a few points that we should discuss:
> 
> Concerns:
> Major version: I consider your the definitions when to bump the major
> version too strict. Given this set of definitions, we would already have
> Kolab 10 or something, which from a user's POV is not much different from
> Kolab 6. Let's not follow the Chrome or Opera madness, because Kolab 42
> sounds really weird.
> 

I'm confused with this one, so let's attempt to clarify where we both stand on 
this.

My thought is that there is a certain set of conditions (upgrade path 
requiring manual intervention as in migration, no existing downgrade path, 
etc.) that would *require* a major version number to be bumped.

> Native packages: I think we should/need to honor the requirements of the
> distributions and their tools.

Agreed.

> This beeing said we should not apply a
> Fedora/RHEL scheme to Debian/Ubuntu, even if it may work.

Nobody ever said we should.

> We should rather
> use ~ to indicate pre-releases and + for post release
> 

I would say the key is to, by whatever means made available through the 
appropriate package management "best practices" and guidelines, we should 
indeed use those semantics. Such, however, is not necessarily consistent 
across distributions, and will form inconsistencies upstream (e.g. with us).

I suppose the question here is, what level of compromise we're willing to 
make, where we make that compromise, what compromise that would be, and on 
which end such compromise would slightly derive from.

That said, the aforementioned notwithstanding, if every distribution provides 
the means to do what we require, we have the knowledge and man-power to deal 
with it, and this is as transparently standardized within our project, then 
sure. Please use your knowledge to improve the KEP if you think it can be 
improved in this area, bearing in mind all of the aforementioned.

> Questions:
> Exceptions for Unstable Bug-fix Releases: x.y.z-rc1 should be x.y.z.rc1,
> right?
> You are mixing delimiters here and I wonder what would be the
> counterpart of x.y.z-rc1 in native packaging.
> 

Purposefully so, yes indeed I am mixing delimiters here. The "alpha", "beta", 
"rc" and "git" are *release* indicators for versioned products (e.g. X.Y.Z). 
Upstream *releases* of the versioned product (e.g. the version is not going to 
change, but anything without the aforementioned release indicators is a final 
release).

> Exceptions for Unstable Bug-fix Releases: 2.3.1.0 would be a final
> (=tested) bugfix release of 2.3.1?
> 

This would be occuring only highly exceptionally, but yes -given that "2.3.1" 
would most likely be "2.3.1-rc1". The next bug-fix release would return to the 
normal 2.3.2.

> Suggestion:
> Pre-releases: Instead of leaving out the teeny 0 for a prerelease of that
> version, we should use te usual major.minor.teeny versioning even for pre-
> releases, but with a high teeny. Example:
> 2.2.0
> 2.2.1, 2.2.2, ... bugfix releases
> 2.2.90 (Alpha of 2.3)
> 2.2.91 (Beta of 2.3)
> 2.2.92 (RC or 2.3)
> 2.3.0 Final
> 

I strongly object against this, because it does not align with pragmatic 
source code management procedures (e.g. tag- and branch-policies), proper 
issue tracking, and development project management.

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/20101124/07a6283e/attachment.html>