On Dec 18, 2006, at 1:49 PM, Kevan Miller wrote:
A "tag" or "label" should never be modified... its a point in
time, not indented (or expected) to be changed.
I'm sympathetic to your concern. However, we don't (to my
knowledge) have a documented release process for our projects. So,
we're currently leaving these practices in the hands of our release
managers.
I understand why you did this... and I think that SVN is probably
more to blame for this by how its "implemented" tagging. Most source
control systems simply don't allow your to make code changes to a
label/tag, most will allow retag from another branch, but not
modification of the label directly. But svn implements tags as
branches which forces the policy of what is a tag and what is a
branch on to the users... which has a rather nasty side-effect of
never really knowing if a tagged code line is a label or a branch.
In this case, it would have been "better" if there was still a 2.0-M1
branch, and you made this change to the branch, and then re-tagged
the changed file.
I really don't think that moving branches to tags, or tags to
branches is a good idea at all... even though svn will let you do
that. Keep the branch around so that you can use it to make changes
you need to, and then always copy to tag... and never change code on
a tag, assume its read-only.
In this case, I did what the release manager asked me to do...
Well, I might have asked if they were smoking crack... and to give me
some. :-P
I would not recommend doing it again though. I believe that
following some best practices for scm (as well as build) will really
improve on Geronimo's ability to deliver in the long term. Little
short-cuts like this will add up over time and slow down the machine
considerably.
So, what do you feel would be the appropriate techniques for
building a release?
This doesn't really related directly to the issue of changing code in
a tag... though it is somewhat related. And this question is a bit
of a loaded gun... but here are some of my thoughts, incomplete as
they maybe at the moment:
I believe that the process of releasing should be automated, and more
so delegated to a well known environment. Automation of releases
helps to ensure that releases are repeatable and reduce the chances
of user error, which in generally will improve the quality and
trustworthiness of releases. Releases should be performed in a well
known environment so that local environmental changes do not
adversely affect the contents or quality of a release.
I believe that once a release is made (and I mean voted out and
official), that no changes should ever be made to that release. If
*anything* needs to be *fixed*, then cut a new release, *never,
never, never* change the release.
Release tags should really be buildable at anytime... be it one day,
2 weeks, 3 years. I know that as time passes the chances of this
holding true begin to diminish, but it is something that we should
aim for. With the proper tools and environment it should be possible
to ensure that each release builds durability is in the years, if not
decades rather than months.
Related to ASF-style releasing, which I still think is a bit odd, but
the whole make a "release", then vote on the release, maybe "re-
cutting" the same release, might be better of using a branch for code
changes (for the recutting), and then a label per cycle, and once a
label is finally blessed it can be renamed to the official release
tag. It is just confusing to move branches to tags, and then back to
branches, and then tags again as we move through this process. I
think we also should include some sort of release/build iteration for
times when we bounce back and forth... for example, 1.2-beta-1 (is
the first), 1.2-beta-2 (is the second). This is commonly used by RPM
packagers, where each package has its iteration, and often the
iteration that is final is not -1, but more like -3 or -4. This is
quite natural if you think of tags as permanent and non-changing...
which I suggest is the best way to consider them for releases...
though don't get me wrong, when using a promotion model, or for
things like tagging last successful nightly builds, etc, then mutable
tags are useful, but definitely not for releases.
* * *
I'm sure that I can come up with more... but I think the most
important part is the automation... release made by me, or by you or
by anyone else on the team, should be for the most part identical. I
believe that the other bits, like svn tag policy, build iteration
inclusion, etc, all fit together as pieces of the automation
puzzle... and in many cases come naturally once you start to think
about the problem as a set of repeatable steps to take that which can
be applied to any project for releases, ci, nightly builds, etc. To
make all of those work using more or less the same system, you need
to have consistency, you need to follow best practices and void
situations where you are forced into making small changes/hacks just
to get something done quickly. There will probably be some burden at
first, but the end result is actually less burden for everyone.
--jason
