[Kolab-devel] Branch naming (was Re: CVS to Mercurial conversion)

[Jeroen van Meeuwen (Kolab Systems)]

Christoph Wickert wrote:
> > "hosted" is a product series, whereas
> > 
> > "debian" is a native packaging effort based on releases.
> 
> First of all: Please don't pick on the term "version" I used. Let's just use 
> your term 'tag' instead.
> 
> What I wanted to point out is that whatever-2.2.4 or 2.2.4-whatever share 
the 
> same codebase (and eventually some changes on top of that). Both - no matter 
> if product or native packaging - will be rebased against the shared codebase 
> with every new release. The release is the what makes them different the 
most 
> and thus should be at the beginning.
> 

The version is always a distinguishing factor between releases, it's what it's 
there for.

It's never at the beginning though. The reason for is, possibly, in part, 
readibility; kolab-2.2.4 / hosted-kolab-2.2.4 reads as:

This is kolab version 2.2.4 or hosted-kolab-2.2.4, two product series that 
are, at the time of this writing;

- targeted at different audiences,
- mutually exclusive,
- developed apart from one another -even though rebased / in the same scm,
- two different upstream tarball releases each with different names.

In a list of tags/branches, sorting comes to mind, too; hosted-kolab 
tags/branches should be grouped together, not mixed in with kolab 
tags/branches.

> > == Hosted Kolab tags ==
> > 
> > A "Hosted Kolab tag" would do exactly the same, but for the "Hosted"
> > product series.
> > 
> > Sane tags in this category would include;
> > 
> > - hosted-kolab-2.2.4.1 (based on kolab-2.2.4 maybe? is immediately
> > indicated) - hosted-kolab-3.0alpha2
> 
> Ok, this is indeed a nice and helpful illustration of what you have in mind, 
> but you are only rephrasing what you said before instead of explaining *why* 
> you think it should be this way.
> 
> Would you mind explaining it (again) for me? What is wrong with 
> kolab-3.0alpha2-hosted? It is kolab 3.0 alpha2 with the hosted patches on 
top.
> 

There's supposed to be three chunks in a tarball. From right to left;

- the first is the extension, to indicate the type of compression,
- the second is the version, which begins right after the last '-' that is 
still in the tarball name after you pop() the extension,
- the third is the product (series) name.

In other words, kolab-2.2.4-hosted.tar.gz simply doesn't parse. It's why the 
Apache foundation is not releasing httpd-2.2.13-docs.tar.gz, but httpd-
docs-2.2.13.tar.gz.

Furthermore, there is the issue of milestones on a roadmap. Some things are 
targeted for the next hosted-kolab release, while other things are targeted 
for the next kolab release. These upcoming releases do not necessarily have a 
version number attached to them already.

A branch in the SCM would have the work related to a ticket on such milestone, 
such as branch hosted-kolab-next, or kolab-next. Not kolab-next-hosted. Most 
commonly, the naming conventions for branches are kept in one line with the 
naming conventions for tags.

While, possibly, not a problem for human eyeballs, I would hate to create 
something that is different from everything else out there.

> > And, since we're making Kolab this awesome one-size-fits-all product, for
> > real 3.0 releases we might even be able to drop the entire hosted- as a
> > product series.
> 
> hopefully, ;) but this has nothing to do with branches, tags, repos 
whatever. 
> The question still stands if tags should be a prefix or a suffix, no matter 
> what kind of tags.
> 

In my not so humble opinion, prefixes are upstream changes to upstream 
releases, which will at some point be released by/through upstream, whereas 
suffixes are used for downstream changes -such as native packaging efforts.

> > However, the hosted consumers do require a different support stream, so
> > keeping the tags for what we release through the appropriate distribution
> > channels would still be sensible (even if they keep ending up on the same
> > scm object).
> > 
> > == Debian tags ==
> > 
> > If there's anything to tag for "debian" in the upstream SCM, then I'd 
argue
> > this would be:
> > 
> > <product>-<version>-<release>.<dist>
> > 
> > Where:
> > 
> > - product is one of "kolab-webadmin", "hosted-kolab-webadmin"
> > - version is 2.2.4, 3.0alpha2, etc.
> > - release is 0.x for pre-releases packaged, 1+ for actual releases 
packaged
> 
> Please don't apply our Fedora versioning scheme to Debian. Debian has 
> different versioning as described at
> http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Version
> 

This isn't the Fedora versioning scheme, and I'm not applying it to Debian. 

I'm applying very common pragmatic source code management standards to our 
*tags* used in our *upstream scm*.

> Pre-releases would have ~1 in contrast to a regular release with 1 or +1.
> 
> > - dist is "lenny", "squeeze", "laughlin", "tikanga"
> 
> Uuah, I don't like this, doesn't really look Debian'ish to me and I'm sure 
> Mattheu will confirm this.
> 

Again, this is the upstream SCM, not Debian, nor Fedora. You can substitute 
what you use to indicate the <dist> with debian4, debian5, fedora14, etc. if 
you will, but that doesn't change the fact you can indicate (in a tag) which 
point in the upstream source code development timeline is used for a target 
platform exactly.

> > An example would be:
> > 
> > - kolab-cyrus-imapd-2.3.16-0.1.squeeze
> 
> Attention, kolab-cyrus-imapd-2.3.16-0.1.woody would be considered greater 
than 
> kolab-cyrus-imapd-2.3.16-0.1.squeeze.
> 

Again, this would have nothing to do with the package management on the 
consumer system obtaining a .squeeze package.

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