struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Cooper <mfncoo...@gmail.com>
Subject Re: CVS -> SVN / Roadmap
Date Thu, 14 Oct 2004 17:38:36 GMT
On Thu, 14 Oct 2004 12:50:49 -0400, James Mitchell <jmitchell@apache.org> wrote:
> 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.

I should be around this weekend. You know where to find me on IM. ;-)

--
Martin Cooper


> 
> --
> James Mitchell
> Software Engineer / Open Source Evangelist
> EdgeTech, Inc.
> 678.910.8017
> AIM: jmitchtx
> 
> 
> 
> ----- Original Message -----
> From: "Don Brown" <mrdon@twdata.org>
> To: "Struts Developers List" <dev@struts.apache.org>
> 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
> > >> <anders@steinlein.no> 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: dev-unsubscribe@struts.apache.org For
> > >> additional commands, e-mail: dev-help@struts.apache.org
> > >>
> > >>
> > >
> > >
> > >
> > >---------------------------------------------------------------------
> > >To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> > >For additional commands, e-mail: dev-help@struts.apache.org
> > >
> > >
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> > For additional commands, e-mail: dev-help@struts.apache.org
> >
> >
> 
> 
> ---------------------------------------------------------------------
> 
> 
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
> 
>

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


Mime
View raw message