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 07:00:01 GMT

On Jan 24, 2008, at 5:42 PM, Kevan Miller wrote:

>
> On Jan 24, 2008, at 8:23 PM, David Jencks wrote:
>
>>
>> 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.
>
> That's not what I recall. There's documentation here -- http:// 
> cwiki.apache.org/GMOxPMGT/release-branching-process.html There were  
> of course dev list postings. Suppose we can try to search back  
> through the list.

Like I said, the documentation is wrong, even if we voted on it and  
haven't discussed since:-)  I'm fairly certain that Dain did not  
release specs through branches but directly from trunk using the  
release plugin.  Should I start a new thread?

basically:

-- for specs, gshell, xbean, components etc, releasing from trunk  
directly using the release plugin is the only way to go
-- for geronimo, we should use the release plugin to create a branch,  
stabilize, and release from a branch.

-- in the hopefully near future we will be releasing small enough  
bits of geronimo so everything or almost everything can be released  
directly without preliminary branching (yes, this might be an  
unrealistic dream)

thanks
david jencks

>
>>
>>
>> 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.
>
> The reason to copy to branches is to help prevent accidental/ill- 
> timed commits as a release was being prepared. Given the infrequent  
> nature of spec development, I don't view this as a big exposure.
>
>>
>> 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