You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Ted Husted <hu...@apache.org> on 2004/04/05 03:14:02 UTC
2.3 for 1.3? (was Counting down to 1.2.1)
So, I'm going to knuckle down and do whatever we need to do to get 1.2.1 ready to cut this week.
In the meantime, I'm wondering if we want to just bite the bullet and move the minimum to servlet 2.3 for the Struts 1.3.x series?
People using 2.2 can still use 1.2.x, and having 2.3 available might simplify some of the configuration discussions we're having now.
Struts 2.0 is being slated for 2.4, so it's a clean continuum.
As to the subproject reorg, I'd imagine we'd still keep taglib-classic on 2.2, and taglib-jstl and taglib-faces on 2.3.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: 2.3 for 1.3? (was Counting down to 1.2.1)
Posted by Michael McGrady <mi...@michaelmcgrady.com>.
Isn't this supposed to be "Jericho"? If it is "Jerico", that will cause
great confusion on Google with Jerico Beach, the island of Java and the use
of struts on airplanes. For an example of this, cf.
http://www.airmuseum.ca/exag0309.html. My understanding is that it is
called "Jericho" because it tears down the walls by providing interfaces
for major components. Is that right?
At 03:48 AM 4/5/2004, Ted Husted wrote:
>On Sun, 04 Apr 2004 23:37:22 -0400, Robert Leland wrote:
> > It may be that a full blown Jerico would be struts 3.0, but we have
> > to start somewhere.
>
>How about this:
>
>In 1.2.x, we've been removing the deprecations and adding some API
>niceties, like wildcard mappings and the "module" tag attributes.
>
>In 1.3.x, we were going to start doing more aggressive things, like bring
>the Struts-Chain RequestProcessor into the Core and finish the move to Maven.
>
>Coincidentally, we are migrating to a TLP (kudos to Martin for all his
>hard work!), and it's likely that 1.3.x will be our first
>"struts.apache.org" release series. We might also have subprojects then,
>so there would be coinciding releases of taglibs-classic, taglibs-jstl and
>taglibs-faces.
>
>So why not just label want we were going to do in 1.3.x as Struts 2.x, and
>start calling Jericho (or whatever else we do -- it's just a whiteboard) 3.x ?
>
>Struts 1.x then remains Servlet 2.2, JSP 1.1, Java 1.2.
>
>Struts 2.x (fka 1.3.x) can then be Servlet 2.3, JSP 1.2, and Java 1.3.
>
>Struts 3.x (fka 2.x) can then be Servlet 2.4 and JSP 2.0, as planned.
>
>There will be some short-term confusion among some developers, since we've
>been saying that 2.x would be the revolution and this change means that
>3.x would then be the revolution (if we don't refactor our way there
>first!). But, I think we can live with that issue if changing release
>numbers solves other problems. [I guess this circumstance is why so many
>teams like to use names rather than numbers :)]
>
>
> > I have been thinking this for a long time. Folks will still have
> > the 1.2.X release series.
> >
> > It may be possible for 1.3 struts to remain backwards compatable,
> > but to start experimenting with servlet 2.3 features.
>
>Agreed.
>
> >From an API perspective, simply moving to servlet 2.3 will not create
> any backward-compatibility issues. The issues are infrastructure and
> deployment compatibility. IMHO, when we talk about
> backward-compatibility, we are referring mainly to the API. If they can
> run the same Struts config, Actions, and JSPs unchanged, under whatever
> platform, then it's backward compatible. What spec level we use is just a
> refection of what our community is using.
>
>A year ago, I still knew people in major corporations who were on 2.2, but
>were looking forward to upgrading to 2.3 in the short term. Another year
>has passed, and I think we should stop living in the past and start
>exploiting the spec our community is using. If we start using filters and
>listeners ourselves, then that will encourage other people to do the same.
>A lot of people need to do Struts-like things with their business objects,
>that they should be doing with filters and listeners, and we can starting
>showing them how. As
>
>
> > I believe we should start moving forward. Perhaps we can adopt
> > Bugzilla's and Linux scheme
> > of even/odd build numbers. Even is stable production releases and
> > odd is development builds. The development
> > builds would give us CVS space to start experimenting with whats
> > been on paper. If we find out that
> > making Struts 1.4 (The stable release) backward compatable based on
> > what is learned with Struts 1.3 development build
> > then we scratch 1.4 and go right to 2.0 (which is by the way an
> > even build number)
>
>I'd lean toward sticking with the HTTPD/Tomcat approach for now.
>
>-Ted.
>
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>For additional commands, e-mail: dev-help@struts.apache.org
Re: 2.3 for 1.3? (was Counting down to 1.2.1)
Posted by Robert Leland <rl...@apache.org>.
Joe Germuska wrote:
>> Struts 1.x then remains Servlet 2.2, JSP 1.1, Java 1.2.
>>
>> Struts 2.x (fka 1.3.x) can then be Servlet 2.3, JSP 1.2, and Java 1.3.
>>
>> Struts 3.x (fka 2.x) can then be Servlet 2.4 and JSP 2.0, as planned.
>
>
> If we are going to depend on Servlet 2.3, then I think it's probably
> worth changing the major version number.
>
>> So why not just label want we were going to do in 1.3.x as Struts
>> 2.x, and start calling Jericho (or whatever else we do -- it's just a
>> whiteboard) 3.x ?
>
>
> However, I don't know if I believe it's worth the potential confusion
> and management overhead to switch to 2.3 "just because". I do think
> it's true that Struts can set an example and help people become
> familiar with new technologies, but why not do Struts 1.3 as we've
> planned it, unless someone has specific features they want to apply
> that we require?
That sounds reasonable, however to allow collaboration/many sets of
eyes, we need CVS space to try out different approaches.
Can we do that with minimal effort, ie without branching the code ?
When we do get to the point of needing a straw man struts CVS 2.0
version we could either branching or starting clean ? I'd vote for
branching, that way there is something to start with.
However, I would BRANCH 2_0 and keep 1.2.X as the main trunk. That way
ii takes and effort to get to the strust 2.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: 2.3 for 1.3? (was Counting down to 1.2.1)
Posted by Joe Germuska <Jo...@Germuska.com>.
>Struts 1.x then remains Servlet 2.2, JSP 1.1, Java 1.2.
>
>Struts 2.x (fka 1.3.x) can then be Servlet 2.3, JSP 1.2, and Java 1.3.
>
>Struts 3.x (fka 2.x) can then be Servlet 2.4 and JSP 2.0, as planned.
If we are going to depend on Servlet 2.3, then I think it's probably
worth changing the major version number.
>So why not just label want we were going to do in 1.3.x as Struts
>2.x, and start calling Jericho (or whatever else we do -- it's just
>a whiteboard) 3.x ?
However, I don't know if I believe it's worth the potential confusion
and management overhead to switch to 2.3 "just because". I do think
it's true that Struts can set an example and help people become
familiar with new technologies, but why not do Struts 1.3 as we've
planned it, unless someone has specific features they want to apply
that we require?
In summary, I'd say "stay the course" until there's a specific
proposal to use Servlet 2.3 features , but if we start using 2.3
features, we should bump the major version. But it seems to me that
any interesting use of Servlet 2.3 is probably going to involve other
sizeable refactorings that would also justify incrementing the major
version number.
Joe
--
Joe Germuska
Joe@Germuska.com
http://blog.germuska.com
"Imagine if every Thursday your shoes exploded if you tied them
the usual way. This happens to us all the time with computers, and
nobody thinks of complaining."
-- Jef Raskin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: 2.3 for 1.3? (was Counting down to 1.2.1)
Posted by Ted Husted <hu...@apache.org>.
On Sun, 04 Apr 2004 23:37:22 -0400, Robert Leland wrote:
> It may be that a full blown Jerico would be struts 3.0, but we have
> to start somewhere.
How about this:
In 1.2.x, we've been removing the deprecations and adding some API niceties, like wildcard mappings and the "module" tag attributes.
In 1.3.x, we were going to start doing more aggressive things, like bring the Struts-Chain RequestProcessor into the Core and finish the move to Maven.
Coincidentally, we are migrating to a TLP (kudos to Martin for all his hard work!), and it's likely that 1.3.x will be our first "struts.apache.org" release series. We might also have subprojects then, so there would be coinciding releases of taglibs-classic, taglibs-jstl and taglibs-faces.
So why not just label want we were going to do in 1.3.x as Struts 2.x, and start calling Jericho (or whatever else we do -- it's just a whiteboard) 3.x ?
Struts 1.x then remains Servlet 2.2, JSP 1.1, Java 1.2.
Struts 2.x (fka 1.3.x) can then be Servlet 2.3, JSP 1.2, and Java 1.3.
Struts 3.x (fka 2.x) can then be Servlet 2.4 and JSP 2.0, as planned.
There will be some short-term confusion among some developers, since we've been saying that 2.x would be the revolution and this change means that 3.x would then be the revolution (if we don't refactor our way there first!). But, I think we can live with that issue if changing release numbers solves other problems. [I guess this circumstance is why so many teams like to use names rather than numbers :)]
> I have been thinking this for a long time. Folks will still have
> the 1.2.X release series.
>
> It may be possible for 1.3 struts to remain backwards compatable,
> but to start experimenting with servlet 2.3 features.
Agreed.
>>From an API perspective, simply moving to servlet 2.3 will not create any backward-compatibility issues. The issues are infrastructure and deployment compatibility. IMHO, when we talk about backward-compatibility, we are referring mainly to the API. If they can run the same Struts config, Actions, and JSPs unchanged, under whatever platform, then it's backward compatible. What spec level we use is just a refection of what our community is using.
A year ago, I still knew people in major corporations who were on 2.2, but were looking forward to upgrading to 2.3 in the short term. Another year has passed, and I think we should stop living in the past and start exploiting the spec our community is using. If we start using filters and listeners ourselves, then that will encourage other people to do the same. A lot of people need to do Struts-like things with their business objects, that they should be doing with filters and listeners, and we can starting showing them how. As
> I believe we should start moving forward. Perhaps we can adopt
> Bugzilla's and Linux scheme
> of even/odd build numbers. Even is stable production releases and
> odd is development builds. The development
> builds would give us CVS space to start experimenting with whats
> been on paper. If we find out that
> making Struts 1.4 (The stable release) backward compatable based on
> what is learned with Struts 1.3 development build
> then we scratch 1.4 and go right to 2.0 (which is by the way an
> even build number)
I'd lean toward sticking with the HTTPD/Tomcat approach for now.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: 2.3 for 1.3? (was Counting down to 1.2.1)
Posted by Robert Leland <rl...@apache.org>.
Ted Husted wrote:
>So, I'm going to knuckle down and do whatever we need to do to get 1.2.1 ready to cut this week.
>
>In the meantime, I'm wondering if we want to just bite the bullet and move the minimum to servlet 2.3 for the Struts 1.3.x series?
>
I have been thinking this for a long time. Folks will still have the
1.2.X release series.
It may be possible for 1.3 struts to remain backwards compatable, but to
start experimenting with
servlet 2.3 features. I had thought about taking a poll, but now think
better of that.
I believe we should start moving forward. Perhaps we can adopt
Bugzilla's and Linux scheme
of even/odd build numbers. Even is stable production releases and odd is
development builds. The development
builds would give us CVS space to start experimenting with whats been on
paper. If we find out that
making Struts 1.4 (The stable release) backward compatable based on what
is learned with Struts 1.3 development build
then we scratch 1.4 and go right to 2.0 (which is by the way an even
build number)
It may be that a full blown Jerico would be struts 3.0, but we have to
start somewhere.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
RE: 2.3 for 1.3? (was Counting down to 1.2.1)
Posted by Ted Husted <hu...@apache.org>.
On Sun, 04 Apr 2004 18:30:09 -0700, Martin Cooper wrote:
> Oh. I thought I was supposed to be cutting it this weekend (at your
> suggestion ;). The only reason that's not actually done is because
> CVS is locking up on me (in the Struts repo only). Should I not be
> trying to do this?
There are nine problem tickets that should be addressed, one way or the other, including one for the mailing list address. I can take care of these early this week, so we can roll it this weekend or before (if that works for you).
We (meaning I) should also put up something on the webstie about the TLP transition, to ease the confusion. :)
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
RE: 2.3 for 1.3? (was Counting down to 1.2.1)
Posted by Martin Cooper <ma...@apache.org>.
> -----Original Message-----
> From: Ted Husted [mailto:husted@apache.org]
> Sent: Sunday, April 04, 2004 6:14 PM
> To: Struts Developers List
> Subject: 2.3 for 1.3? (was Counting down to 1.2.1)
>
>
> So, I'm going to knuckle down and do whatever we need to do to
> get 1.2.1 ready to cut this week.
Oh. I thought I was supposed to be cutting it this weekend (at your
suggestion ;). The only reason that's not actually done is because CVS is
locking up on me (in the Struts repo only). Should I not be trying to do
this?
> In the meantime, I'm wondering if we want to just bite the bullet
> and move the minimum to servlet 2.3 for the Struts 1.3.x series?
I feel pretty strongly that we shouldn't be breaking backwards compatibility
in a point release.
> People using 2.2 can still use 1.2.x, and having 2.3 available
> might simplify some of the configuration discussions we're having now.
I haven't caught up completely on that thread yet. (Long messages sometimes
get pushed down on my stack, I'm afraid, and I was trying to focus on
1.2.1.) What is it about moving to 2.3 that would help (other than allowing
for the mechanism I suggested, which would be optional anyway)?
> Struts 2.0 is being slated for 2.4, so it's a clean continuum.
>
> As to the subproject reorg, I'd imagine we'd still keep
> taglib-classic on 2.2, and taglib-jstl and taglib-faces on 2.3.
Right now (or at least after 1.2.1 is out), I think we need to focus on the
other parts of our TLP move. I'll start a separate thread on that.
--
Martin Cooper
> -Ted.
>
>
>
> ---------------------------------------------------------------------
> 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