geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Dillon <ja...@planet57.com>
Subject Re: svn commit: r488326 - /geronimo/server/tags/2.0-M1/testsuite/deployment-testsuite/manifestcp/manifestcp-ejb/src/main/resources/META-INF/ejb-jar.xml
Date Mon, 18 Dec 2006 23:48:06 GMT
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



Mime
View raw message