You are viewing a plain text version of this content. The canonical link for it is here.
Posted to pluto-dev@portals.apache.org by Elliot Metsger <em...@jhu.edu> on 2007/02/26 15:25:15 UTC
Pluto website (was: Re: Pluto 1.1.0 distributions are up)
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
>>
>>
>>
Re: Pluto website
Posted by "David H. DeWolf" <dd...@apache.org>.
> If no one beats me to it, I'll send out an
> announcement in the morning.
>
Done. Also posted to the serverside. We can consider this release
complete as far as I'm aware. On to 1.1.1 (or whatever we call it :D)
Re: Release Versioning (was Re: Pluto website)
Posted by Elliot Metsger <em...@jhu.edu>.
David H. DeWolf wrote:
> 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.
This sounds like a practical, common sense approach.
For example, 1.1.1 is not a drastic code refactor and the changes going
into 1.1.1 (both the number of changes and the scope of the changes are
"small") probably won't result in a "beta" or "alpha" designation. So
we can vote and ship 1.1.1 GA relatively quickly.
On the other hand, when 286 is merged into trunk and we are ready to
make a release, it may be that based on test results, a "beta"
designation is appropriate and useful to the community.
My original concern when I proposed dropping alpha and beta from
releases was expediency. I would prefer to not have to go through
posting a build designated "beta" if we feel it is GA quality.
Elliot
Re: Release Versioning (was Re: Pluto website)
Posted by CD...@hannaford.com.
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" <dd...@apache.org> 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
> >>>>>
> >>>>>
> >>>>>
> >>>
> >>
> >>
> >>
> >
> >
> >
Release Versioning (was Re: Pluto website)
Posted by "David H. DeWolf" <dd...@apache.org>.
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
>>>>>
>>>>>
>>>>>
>>>
>>
>>
>>
>
>
>
Re: Pluto website
Posted by Craig Doremus <cd...@apache.org>.
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
>>>>
>>>>
>>>>
>>
>
>
>
Re: Pluto website
Posted by "David H. DeWolf" <dd...@apache.org>.
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
>>>
>>>
>>>
>