struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ted Husted <>
Subject Re: [ANNOUNCEMENT][shale] Struts Shale 1.0.0 Release Candidate 1 Available
Date Sat, 26 Nov 2005 16:08:29 GMT
I'm not sure if I'm comfortable with going back to using the "release
candidate" nomenclature. If we want to release a distribution, we
should vote on the plan, and release a distribution. If that
distribution needs work to make the GA grade, then we should just
release the next milestone. We worked very hard to develop a canonical
release process, which I believe is serving us well.

If we anticipate that a 1.0.0 release will be soon followed by a
1.0.1, then I would suggest setting up a release plan for the
subsequent release too. There's no reason why we can't use the
canonical process to release early and release often. Since the
release process is already streamlined, I don't think that hosting
"release candidates" and "limited time distributions" on top of the
nightly builds is a good idea.

I am also very uncomforable with us rolling any type of distribution
and announcing it to the *user* list, without (as far as I can tell)
any prior discussion on dev@. There are several Shale committers in
our community, and I believe everyone involved should be given the
express opportunity to chime-in before we do anything like this.


On 11/25/05, Craig McClanahan <> wrote:
> In preparation for the initial milestone release of Struts Shale 1.0.0, a
> release candidate has been made available at:
> including both tar.gz and zip artifacts (containing both binary and source),
> and an extracted copy of the release notes.  Please help ensure the correct
> assembly and quality of this release by downloading it, and ensuring that it
> works correctly for you.
> Struts Shale 1.0.0 is intended to be an initial test build of the new
> framework (see <> for more
> information).  It is not intended that this release be subsequently voted on
> as candidate for General Availability.  Instead, it should be considered an
> alpha milestone, released in order to provide opportunities for wider
> testing.  Expect to see subsequent point releases of increasing quality and
> functionality.
> Even though this is considered a test build, various developer APIs should
> be considered at a more stable (in terms of assurances of backwards
> compatibility in future releases) point than might otherwise be expected of
> an alpha release.  Please see the following web page for more details:
> Feedback welcome!
> Craig McClanahan

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message