I did not mean to imply that we were going to change our release process
in saying that we should cut 1.1.1. If we want to release the next
build as 1.1.1-alpha, that's fine. . .it's just that it's easier to call
the next build 1.1.1 since we haven't discussed it's quality yet :)
Anyways, thanks for bringing this up. Now that you mention it, I do
think that we should change to the "cut test build and then vote on
quality" approach, and to some extent I think it's required. But, the
fact is, that it's probably up to the PMC to decide.
There's been discussion about this lately on the bridges list. Here's
what Carsten said:
> Yes, this is more or less a requirement for releases at Apache. The vote
> has to be done on a concrete tarball. So this means whenever you're
> ready prepare the tarball (including tagging etc) and vote on it.
> If for any reason the vote fails, this means increasing the version
> number! So if you prepare a 1.0.1 release, the vote fails, the next
> official release will be 1.0.2 to avoid confusion. There was an
> interesting thread recently on the jackrabitt developer list about this
> topic.
>
> Carsten
I personally like this. The idea is that you cut the "test build" and
then vote on it's quality. We can publish on the website whether a
particular build is alpha, beta, or ga, but it's not part of the actual
build name. This approach is consistent with not only struts, but many
other apache projects (tomcat, tiles, http, etc. . .).
The biggest advantage is that IMHO the release process becomes easier to
manage. Instead of having to wait around for everything to be perfect
if we're trying to cut a GA release, we can cut the test build and vote
on the quality after the fact. If it fails, we remove it and move on.
If it's good, but not great, we can call it a beta and move on. In
short, if we take this approach, I would hope that we get more frequent
releases.
David
Craig Doremus wrote:
David:
I tried to publish the site, but I had problems logging in when I ran
the site:deploy goal, so thanks for moving this along. Please add
anything to the news item that I created that you think is appropriate
and send it out.
I noticed that you want to push out version 1.1.1 soon. Are we doing
away with alpha, beta and rc release designations? If, so, how does
someone judge the quality of a release? I notice that Struts 2.0 has
gone this way. I find this way to do versioning very confusing.
/Craig
Craig,
Thanks for making the doc updates. I've published the site tonight.
Feel free to make more mods and then update again. . .I just wanted to
get something out. If no one beats me to it, I'll send out an
announcement in the morning.
David
Elliot Metsger wrote:
Hi Craig,
Thanks for the updates!
A couple of notes:
1. The release plugin deploys the website (this may or may not be
desired behavior when we are cutting a release candidate).
2. I'm working on a Velocity template which will interpolate strings
in our website content (under pluto-site/src/site/xdoc), allowing us
to automate version numbers. For example, from
pluto-site/src/site/xdoc/index.xml there's the highlightBox for
downloading Pluto, and it references beta2:
Download Pluto 1.1.0-beta2 (19Mb)
I'd like the version string to be interpolated, so the source becomes
Download Pluto ${version}
This goes back to automating version numbers when we release.
If you can update the website and send out the announcements, that
would be appreciated.
After I get the Velocity template in a good place, I'll probably
re-deploy the website but that won't happen until later this week.
Elliot
Craig Doremus wrote:
Elliot:
Thank you all you've done on this release. I added a few things to
the wiki page that still needs to be done, which includes updating
the web site and sending out announcements of the release. I can
help you with this if you want.
/Craig
Ok,
The Pluto 1.1.0 distributions should be up.
I've copied the distribution files from
/www/people.apache.org/builds/portals-pluto and placed them in
/www/www.apache.org/dist/portals/pluto under BINARIES/v1.1.0 and
SOURCES/v1.1.0.
I've digitally signed them, and md5'ed them.
I've created the "current" symlinks in
/www/www.apache.org/dist/portals/pluto to point to the actual files
under BINARIES/v1.1.0 and SOURCES/v1.1.0.
I documented what I did at
http://wiki.apache.org/portals/Pluto/CuttingRelease.
So, all that is left to do, I believe, is update and generate the
website for 1.1.0.
Let me know if I've missed something!
Thanks,
Elliot
