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
