[Kolab-devel] Branch naming (was Re: CVS to Mercurial conversion)
Jeroen van Meeuwen (Kolab Systems)
vanmeeuwen at kolabsys.com
Fri Sep 3 12:44:45 CEST 2010
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
> 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
> and thus should be at the beginning.
The version is always a distinguishing factor between releases, it's what it's
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
> > == 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-22.214.171.124 (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
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-
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
> 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
> > 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
> Please don't apply our Fedora versioning scheme to Debian. Debian has
> different versioning as described at
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
> > 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
Again, this would have nothing to do with the package management on the
consumer system obtaining a .squeeze package.
Jeroen van Meeuwen
Senior Engineer, Kolab Systems AG
e: vanmeeuwen at kolabsys.com
t: +316 42 801 403
pgp: 9342 BF08
More information about the Kolab-devel