David,
I'm fine with any new versioning scheme, just as long as it is well
defined and documented. I think we need to have at least some 'sub GA'
designation for releases to indicate quality of the build. Perhaps just
sticking with the Release Candidate designation is the best way to do
this.
I have been following the progression of Struts 2 on the mail list from
time to time, and I found it puzzling figuring out what was the purpose of
all those micro releases (2.0.2, 2.0.4, 2.0.5, etc). Developers should
remember that release numbers/monikers are important to users too.
/Craig
"David H. DeWolf" <[EMAIL PROTECTED]> wrote on 02/28/2007 07:47:07 AM:
>
> 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
> >>>>>
> >>>>>
> >>>>>
> >>>
> >>
> >>
> >>
> >
> >
> >
