geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com>
Subject Re: Spec development/release process documentation
Date Fri, 25 Jan 2008 01:23:13 GMT

On Jan 24, 2008, at 1:49 AM, Rick McGuire wrote:

> David Jencks wrote:
>> The specs tree seems to be in a mess with stuff in branches and  
>> waay too much stuff in trunk, and many trunk poms having a xxx- 
>> SNAPSHOT version where the latest tag is xxx.
>>
>> I've attempted to document our previous decisions on spec  
>> development and release in specs/branches/README:
>>
>> WARNING
>>
>> DO NOT DEVELOP ANY SPECS UNDER BRANCHES OR COPY ANY VERSIONS INTO  
>> BRANCHES
>>
>> ALL DEVELOPMENT MUST TAKE PLACE UNDER TRUNK
>>
>> ANY CODE UNDER BRANCHES IS AN ERROR AND SHOULD BE CLEANED UP AS  
>> SOON AS POSSIBLE
>>
>> and specs/trunk/README.txt:
>>
>> Structure
>> ========
>>
>> Only specs under active development should be in trunk.  Once you  
>> release, delete the trunk.  If you need to make a change or  
>> bugfix, copy the latest tag into trunk and work with that.
>>
>> Be certain that all dependencies are marked "provided"
>>
>> Do not copy any code into branches under any circumstances.
> I'm not sure I agree with this.  The documented procedures for  
> releasing involves moving the trunk version into branches using the  
> eventual final release name.  Once moved, the poms are updated to  
> remove the -SNAPSHOT and the release candidates are built.  Any  
> changes resulting from the voting process get made in the branch,  
> and only once the release vote has passed is the branched moved  
> into the tag.
> I do like that aspect of the process, since it allows you to see at  
> a glance what stage you're in.  The other principles I agree with.   
> All development should take place in trunk.  No changes should be  
> made to any files once it is tags.  Branches should be reserved  
> just for that transitional zone between termination of active  
> development and finalization of the release.

I guess I need to re-read the documentation for how to do a release,  
but I think it's wrong.  In particular I thought what we voted on had  
to be built from a tag, not something in branches or trunk.  I  
thought if a release vote failed we deleted the tag.

For the specs at least, which we release individually, there is no  
point in copying anything to branches.  The release plugin can create  
the tag directly from trunk just fine and much better than I could by  
hand.  When it constructs the release artifacts it checks out from  
the tag it created.

So, I don't see the point in branches unless we are actually going to  
branch or need to do manual cleanup before a release (such as with  
all of geronimo at present.... an unfortunate situation)

thanks
david jencks

>
> Rick
>
>
>>
>> Building
>> ========
>>
>> The is normally no root pom, so you need to build specs individually.
>>
>> To build you will need:
>>
>>  * J2SE SDK 1.5+ (http://java.sun.com/j2se/1.4.2)
>>  * Maven 2.0.7+ (http://maven.apache.org)
>>
>> To build all changes incrementally:
>>
>>     mvn install
>>
>> To perform clean builds, which are sometimes needed after some  
>> changes to the
>> source tree:
>>
>>     mvn clean install
>>
>>
>> Releasing
>> =========
>>
>> Use the maven-release-plugin.
>>
>> Stage to your people.apache.org account or to your local machine  
>> and scp to people.apache.org.
>>
>> After a release vote has passed use the maven-stage-plugin to  
>> transfer the voted artifacts to the apache release repo.
>>
>>
>> -----------------------------------
>>
>> Please review, fix, and if you think this isn't what we agreed on  
>> complain.
>>
>> thanks
>> david jencks
>>
>>
>


Mime
View raw message