Ted, I will roll a release as soon as you say 'go'.

If you and/or Martin (or anyone else that has time and patience to deal with
me) could help with questions wrt label/branch/etc.



--
James Mitchell
Software Engineer / Open Source Evangelist
EdgeTech, Inc.
678.910.8017
AIM: jmitchtx

----- Original Message -----
From: "Don Brown" <[EMAIL PROTECTED]>
To: "Struts Developers List" <[EMAIL PROTECTED]>
Sent: Thursday, October 14, 2004 11:30 AM
Subject: Re: CVS -> SVN / Roadmap


> Ted Husted wrote:
>
> >+1
> >
> >Let's stick to the roadmap we laid out in July.
> >
> >http://struts.apache.org/roadmap.html
> >
> >I'll update the site to reflect the CVS/SVN changes this weekend and
bring the roadmap page up to date.
> >
> >If James is up for rolling a 1.2.5 release, that's fine with me.
> >
> >Either way, it may be time to call 1.2.x a branch and dub the head 1.3.x,
and bring down that-there Struts Chain gizmo. :)
> >
> >
> +1  I vote we (or perhaps I specifically) integrate struts-chain this
> weekend.  It is stable, and I've been using it in production for some
> time without problems.  Course that also means we (again, perhaps I
> specifically) should release commons-chain 1.0.  Ted, there are a few
> Guinnesses in it if you help me with the documentation.... :)
>
> >And if Don wants to start setting up struts-flow and struts-scripting
along the same lines as struts-faces, I'll buy him a Guiness (or three) at
ApacheCon :)
> >
> >
> Ah, Guinness - the ultimate currency.  You got yourself a deal.
>
> Don
>
> >-Ted.
> >
> >On Wed, 13 Oct 2004 13:45:58 -0700, Craig McClanahan wrote:
> >
> >
> >> On Wed, 13 Oct 2004 22:23:32 +0200, Anders Steinlein
> >> <[EMAIL PROTECTED]> wrote:
> >>
> >>
> >>> Forgive my possible ignorance, but what is the policy on new
> >>> releases? I've understood that we can release whenever we want,
> >>> that version numbers are cheap and that you vote whether to make
> >>> a release alpha/beta/GA. But, what goes into a release? Does new
> >>> features/enhancements go into a 1.2.x release, or is it strictly
> >>> bug fixes?
> >>>
> >>>
> >>>
> >>>
> >> What we've talked about before is along these lines:
> >>
> >> Within the 1.2.x series, it's fine to fix bugs and add new stuff,
> >> but not fine to make any backwards-incompatible changes.
> >>
> >> For a 1.3.x series, we could be more liberal about adding new
> >> stuff, and possibly have some deprecations in 1.2.x that get
> >> removed -- but it shoujld in general be based on similar enough
> >> architectural principles that there be a clear upgrade path.
> >>
> >> The challenge, of course, is when do you make that split for the
> >> evolutionary path?  I'd say that something as fundamental as using
> >> Struts Chain instead of the monolithic RequestProcessor, and the
> >> other changes we could make as a result of having that, would be
> >> good grounds for a 1.3.x series.  If that were to start in the
> >> short term, then thinking of 1.2.x as being in maintenance mode
> >> seems likely (although if there's willingness to port features back
> >> and forth, it need not go that way immediately ... for example,
> >> Tomcat 4.1.x continued to develop for a little while at the
> >> beginning of 5.0.x, including some features ported back and forth,
> >> but this pretty much stopped as soon as there was a solid 5.0.x
> >> release for people to use).
> >>
> >> For a 2.x chain, we could have the freedom to be somewhat more
> >> aggressive at rearchitecting ("if we'd known then what we know now,
> >> what would Struts have looked like?"), and could in theory have a
> >> series of alpha releases in parallel with stable releases on 1.2 or
> >> 1.3.  As others have pointed out, how much simultanaeity there is,
> >> and how often releases happen, is more based on the directed energy
> >> of the committers (and what they want to work on), and less on
> >> whether there are parallel development efforts going on.
> >>
> >>
> >>
> >>> The reason I ask is because I would love releases much, much more
> >>> often, but as have been pointed out, incompatibilities/quirks
> >>> between minor versions could be a disaster.
> >>>
> >>>
> >>>
> >>>
> >> Historically, I'd say our 1.0 -> 1.1 transition was, in terms of
> >> interoperability and upgrade, a bit on the edge of what most users
> >> liked, while the 1.1 -> 1.2 transition was much easier to do.  We
> >> haven't actually gotten around to many x.y.z releases on 1.0 or
> >> 1.1, so having them happen at all in 1.2 should be a refreshing
> >> change :-). But I agree with you that compatibility is especially
> >> important within an x.y release cycle.
> >>
> >>
> >>
> >>> \Anders
> >>>
> >>>
> >>>
> >> Craig
> >>
> >> --------------------------------------------------------------------
> >> - 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]
> >
> >
> >
>
>
> ---------------------------------------------------------------------
> 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]

Reply via email to