directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com>
Subject Re: [Releasing process] was Re: [VOTE] Release ADS 1.5.0
Date Thu, 22 Mar 2007 13:05:45 GMT

On Mar 21, 2007, at 7:33 PM, Emmanuel Lecharny wrote:

> I would add that we could follow more or less the process described  
> in http://cocoon.apache.org/devinfo/releasing.html
>
> This seems to be pretty reasonable. Tagging the trunk is not really  
> complicated.
>
> wdyt ?

I think that's pretty much completely unreasonable for a project  
built with maven.

IIUC the process incubator projects seem to be gravitating towards  
goes something like this:

1. everyone agrees informally that it's time for a release and  
someone is selected as release manager.

2. jiras, code, docs etc are cleaned up

3. mvn release is used to tag svn and push proposed artifacts to a  
staging location, normally the release managers' space on  
people.apache.org

4. Everyone goes over the proposed artifacts with a fine toothed comb  
checking the legal requirements and whether they actually work (in  
order of importance :-)

5. The vote occurs on the proposed binary artifacts + the svn tag.

- if the vote passes, the tag remains and the artifacts are moved to  
the apache maven repo (using the appropriate maven goal which I don't  
know)
- if the vote fails (usually because a jar is missing LICENSE and/or  
NOTICE files) the tag is removed, the build number is incremented,  
and everyone goes back to step 2.

I actually like this process.

thanks
david jencks

>
> Emmanuel Lecharny a écrit :
>
>> David Jencks a écrit :
>>
>>> I think we should release 1.5 "now" but in all the other projects  
>>> I'm  involved with a vote happens after the code is tagged and  
>>> the actual  artifacts that are proposed for release are built,  
>>> staged, and ready  for examination by the voters.  That way you  
>>> know exactly what the  code you are voting on is (its been  
>>> tagged) and you can look at the  artifacts and check for proper  
>>> legal files (something that always  seems to get messed up  
>>> between thinking you're ready for a release  and actually  
>>> building the artifacts).
>>
>>
>> Basically, due to the small number of committers, we just rely on  
>> the number of JIRA issues to say ! "let's release" now. Of course,  
>> this is faked because when we feel like it's time to release, we  
>> usually postpone some issues. It would be much better to have  
>> strict roadmaps, to stick to them, and to [VOTE] only when we have  
>> frozen/tagged the release. If the [VOTE] is 'no', then we unfrost  
>> the project, clean the last issues, and [VOTE] again.
>>
>>>
>>> What is the usual apacheds process?  Is this a opinion poll on   
>>> whether to tag, build, stage, and vote or the actual release  
>>> vote?   If the latter, how do you know what you're voting on?
>>
>>
>> We are lucky to be able to use a shorter cycle right now, but I  
>> can feel in my bones that it won't last forever... The more users  
>> we will have, the more 'rigid' we will have to be. Let say that  
>> for 1.5.0, which is an intermediate release, we want to release  
>> fast, because we will add new features soon (1.5.1 and 1.5.2). As  
>> you can see, we didn't had any RC, when we have had 4 RC for 1.0.  
>> You can bet that 2.0 will be much more strict regarding release  
>> process.
>>
>> It's not perfect... but we can work on a better process.
>>
>>>
>>> thanks
>>> david jencks
>>>
>> Emmanuel
>>
>


Mime
View raw message