[kepler-dev] Tagging and Branching

[Bertram Ludaescher]

Hi ChristopherB:

The way I read ChristoperT's email is that he was primarily concerned
about an inconsistent use of tags (never mind branches). A tagged
version must not be changed. It is assigned once to capture a
particular snapshot of the system. Branches evolve; tagged versions
don't.

I think we need to strictly enforce this, at least for Kepler where
3rd party groups (such as ChristopherB's projects) critically depend
on the correct use of tags.

For bug fixes, just evolve the branch further and create a new tagged
version if necessary.

Seems one can have the cake and eat it (as long as the rules are observed).


Bertram



On Fri, Jun 20, 2008 at 4:18 PM, Christopher Brooks
<cxh at eecs.berkeley.edu> wrote:
> Hi Christopher,
> Thanks for sending this around.
>
> How I used branches and tags in CVS for Ptolemy is documented in
> $PTII/doc/coding/releasemgt.htm
>
> Basically, I usually run something like:
>  cvs tag -b rel-7-0-beta-2
> which creates a branch.
>
> I'll use that branch for the beta and for the final release.
>
> I tend to add fixes to the branch after the release in case there is
> another incremental release soon after the major final release.  I
> don't do this lightly, usually I only update the release branch with
> fixes to significant problems.  I really try to avoid adding new
> features to the release branch after a release.  I'm usually fairly
> successful.
>
> I tend not to tag releases, I just use a branch.  I do use dates quite
> a bit.  I don't mind having tags added to the ptII repository.  I'd
> prefer not to have lots of branches added to the ptII repository though.
>
> I realize this is idiosyncratic, but it is simple at it works.
>
> I agree that branch-when-needed is preferred.
>
> I prefer that the trunk always work and that people avoid working in
> branches, it adds complexity.  Most changes can be small atomic
> changes that leave the tree stable.  I've found that when developers
> work outside the trunk for more than a few days that there can be big
> problems when trying to merge.
>
> I think that having a stable release branch that changes roughly once
> a year is a win for people who want stable code and don't want to live
> on head of the devel trunk.
>
> _Christopher
>
>
>
>
>
> --------
>
>
>
>    Hi all,
>
>    I did not get any answer to my email asking how tags and branches are
>    currently used in Kepler and Ptolemy. I just want to have things
>    clear. Please read the following summary:
>
>    SUMARRY:
>
>    TAGS ARE SNAPSHOTS AND ARE STATIC: NO CHANGES ALLOWED
>
>    BRANCHES ARE USE FOR SEPERATED DEVELOPEMENT: CHANGES ALLOWED
>
>    If you disagree, then we might have a problem and we really need to
>    discuss this.
>
>    Below some more details:
>
>    Tag:
>
>    A tag or label refers to an important snapshot in time, consistent
>    across many files. These files at that point may all be tagged with a
>    user-friendly, meaningful name or revision number. See the discussion
>    of baselines, labels, and tags.
>
>    Branch:
>
>    A set of files under version control may be branched or forked at a
>    point in time so that, from that time forward, two copies of those
>    files may be developed at different speeds or in different ways
>    independently of the other.
>
>    References:
>
>    http://en.wikipedia.org/wiki/Branching_(software)
>
>    http://en.wikipedia.org/wiki/Revision_tag
>
>    http://en.wikipedia.org/wiki/Revision_control
>
>    One important features of SVN is the use of global revision numbers
>    that are actually as accurate as tags.
>
>    Maybe cvs users should have a look at the following link:
>
>    http://svnbook.red-bean.com/en/1.1/apa.html#svn-ap-a-sect-1
>
>    Branch strategy:
>
>    There are several ways of using branches. Based on the information I
>    found here:
>
>    http://svn.collab.net/repos/svn/trunk/doc/user/svn-best-practices.html
>
>    The Branch-When-Needed system seams to be the best for Kepler:
>
>    Pros: /trunk is guaranteed to be stable at all times. The hassle of
>    branching/merging is somewhat rare.
>
>    Cons: Adds a bit of burden to users' daily work: they must compile and
>    test before every commit.
>
>    I hope things are clear now,
>
>    Best regards,
>
>    Crhistopher Tuot
>
>    --
>    ______________________________________________________________
>    Dipl.-Ing. Christopher Tuot
>    DFKI GmbH (German Research Center for Artificial Intelligence)
>    Knowledge Management Department
>    POBox 2080, 67608 Kaiserslautern, Germany
>    fon:   +49(0)631 / 20575 - 127
>    fax:   +49(0)631 / 20575 - 103
>    mail:  christopher.tuot at dfki.de
>    web:   http://www.dfki.de
>    ______________________________________________________________
>    Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH
>    Firmensitz: Trippstadter Strasse 122, D-67663 Kaiserslautern
>
>    Geschaeftsfuehrung:
>    Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster (Vorsitzender) Dr. Walter
>    Olthoff
>
>    Vorsitzender des Aufsichtsrats:
>    Prof. Dr. h.c. Hans A. Aukes
>
>    Amtsgericht Kaiserslautern, HRB 2313
> _______________________________________________
> Kepler-dev mailing list
> Kepler-dev at ecoinformatics.org
> http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-dev
>
>