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

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

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  
kolab.org wiki?

Any special ideas concerning short lived topic branches? Or branches  
for developer play areas?

Thanks!

Gunnar

>
> 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
> https://kolab.org/mailman/listinfo/kolab-devel
>

--
Gunnar Wrobel
Developer, Kolab Systems AG

e: wrobel at kolabsys.com
t: +49 700 6245 0000
w: http://www.kolabsys.com

pgp: 9703 43BE

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.