On 2/7/07, Philip Luppens <[EMAIL PROTECTED]> wrote:
On 2/7/07, Rene Gielen <[EMAIL PROTECTED]> 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.
Full +1 for this.
./alex
--
.w( the_mindstorm )p.
>
> Craig McClanahan schrieb:
> > On 2/6/07, Don Brown <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
--
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]