struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Philip Luppens" <philip.lupp...@gmail.com>
Subject Re: Struts Release Process (again) (was [VOTE] Struts 2.0.5 Quality)
Date Wed, 07 Feb 2007 08:38:12 GMT
On 2/7/07, Rene Gielen <gielen@it-neering.net> wrote:
> Craig,
>
> So feature freeze and branch 2.0.x now, only fix reported bugs from beta
> tests and roll out the result as GA, while trunk moves on to 2.1.x,
> fully open for new features and whatever? IMO this would be the perfect
> way to go, you get a big +1 from me on this :)
>
> - Rene

+1
I totally agree with this.

>
> Craig McClanahan schrieb:
> > On 2/6/07, Don Brown <mrdon@twdata.org> wrote:
> >>
> >> Alexandru Popescu wrote:
> >> > I see two clear stages:
> >> >
> >> > - a product that is ready from developers point of view
> >> > - a product that gets its users acceptance
> >> >
> >> > [...]
> >
> >
> > That is definitely one of the lessons to be learned from the Struts
> > 1.xexperience.  Here's how we're applying that lesson in Shale land.
> > The
> > recent 1.0.4 release is the first one we felt had a snowball's chance at
> > being voted GA quality, so as soon as we cut that release we also branched
> > (SHALE_1_0_X), with the rule that only bugfixes (including non-invasive
> > bugfixes backported from the trunk) would be committed here.  The trunk was
> > then opened for further "new feature" development (as well as bugfixes).
> > Right now, it is tentatively labelled as "1.1.0-SNAPSHOT", but that could
> > easily become 2.0.0-SNAPSHOT if we wanted to do major
> > non-backwards-compatible changes.
> >
> > The net effect is that Struts could:
> >
> > * Create a branch totally focused on stabilization and bugfixes ... the
> > only
> > *point*
> >  is to create a GA-quality branch based on the current feature set.  If
> > 2.0.5 does not
> >  cut the mustard, just fix the reported bugs and try again (weeks instead
> > of years later).
> >
> > * Avoid slowing down new feature development ... it continues on the trunk.
> >
> > * If 2.05 (say) got voted GA but a security vulnerability or critical bug
> > were later
> >  discovered, an updated version could be turned around VERY quickly on the
> >  branch.  Just fix the bad problems and release it.  You don't have to
> > worry about
> >  stabilizing all the new features that might have been added on the trunk,
> > because
> >  they won't be present on the branch.  (The MyFaces folks are currently
> > paying
> >  the same price we paid in 1.x, because they are intermixing new features
> > and
> >  bugfixes on the trunk -- hopefully they will learn the same lesson.)
> >
> > Branches are our friends.  The fact that we didn't leverage them is the
> > biggest thing we did wrong in Struts 1.x development, IMHO.  I hope that
> > the
> > Struts 2 process can improve based on lessons learned from that experience.
> >
> > Don
> >
> >
> > Craig
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>


-- 
iDTV System Engineer
"Always code as if the guy who ends up maintaining your code will be a
violent psychopath who knows where you live." - John F. Woods

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org


Mime
View raw message