[Kolab-devel] Branch naming (was Re: CVS to Mercurial conversion)
wrobel at kolabsys.com
Thu Sep 9 22:50:03 CEST 2010
Zitat von "Jeroen van Meeuwen (Kolab Systems)" <vanmeeuwen at kolabsys.com>:
> 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
> 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
>> > == 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-184.108.40.206 (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
> 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
> 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
> Again, this would have nothing to do with the package management on the
> consumer system obtaining a .squeeze package.
Ping to both Christoph and Jeroen. I think this has not been resolved
yet. I admit I don't care that much but wouldn't mind to have a
guideline we adhere to. Can you put such a guideline into the
Any special ideas concerning short lived topic branches? Or branches
for developer play areas?
> 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
> Kolab-devel mailing list
> Kolab-devel at kolab.org
Developer, Kolab Systems AG
e: wrobel at kolabsys.com
t: +49 700 6245 0000
pgp: 9703 43BE
This message was sent using IMP, the Internet Messaging Program.
More information about the devel