You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by James Turner <tu...@blackbear.com> on 2003/04/26 22:04:14 UTC
Craig's back, so I'm asking again...
Craig, we had a vote in your absence to do an RC2 release with the idea
that we could slipstream DBCP and Pool into the final release, since
that's all we're waiting for. It had general consensus agreement but
failed because Aaron -1'd it since you weren't here. Now that you're
back, I'm re-raising the question.
James Turner
Directory of Software Development, Benefit Systems, Inc.
Chair, COMDEX 2003 Strategic Open Source Track
turner@blackbear.com
Author:
MySQL & JSP Web Applications: Data Driven Programming Using Tomcat
and MySQL
Struts Kick Start
Forthcoming:
JavaServer Faces Kick Start
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Craig's back, so I'm asking again...
Posted by Martin Cooper <ma...@apache.org>.
On Sat, 26 Apr 2003, Craig R. McClanahan wrote:
>
>
> On Sat, 26 Apr 2003, James Turner wrote:
>
> >
> > Craig, we had a vote in your absence to do an RC2 release with the idea
> > that we could slipstream DBCP and Pool into the final release, since
> > that's all we're waiting for. It had general consensus agreement but
> > failed because Aaron -1'd it since you weren't here. Now that you're
> > back, I'm re-raising the question.
> >
>
> In general, this sounds like a reasonable approach. However ...
>
> It looks to me like we've got solid release versions for:
> + commons-beanutils 1.6.1
> + commons-collections 2.1
> + commons-digester 1.5 (fixes a backwards incompatibility
> in 1.4.1, release underway now)
> + commons-lang 1.0.1
> + commons-logging 1.0.3
> + commmons-validator 1.0.2
> + jakarta-oro 2.0.7
>
> But don't we still have issues with *all* of the following?
> - commons-dbcp
> - commons-fileupload
> - commons-pool
>
> Martin, where are we on a final FileUpload release?
I expect to commit the bulk of the changes very soon (hopefully tonight).
A little more cleanup, and it will be ready for a Beta 2 that includes
deprecations. I'll update Struts, of course, and I plan to submit patches
for Tomcat and Turbine that avoid the deprecated methods.
I'm not sure how quickly I can reasonably make the transition from Beta to
an RC that removes the deprecated methods, but that's the next step, and
then a Final release.
--
Martin Cooper
>
> Note that, as a process issue, release votes are majority, not consensus:
> http://jakarta.apache.org/site/decisions.html
> so it would have been "legal" to do an RC2 release anyway, in spite of a
> -1, if there were still a majority of +1s.
>
> Also, it looks like we should finish deciding how to deal with Bugzilla
> #18888 before an RC2 release.
>
> Craig
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Craig's back, so I'm asking again...
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Sat, 26 Apr 2003, James Turner wrote:
>
> Craig, we had a vote in your absence to do an RC2 release with the idea
> that we could slipstream DBCP and Pool into the final release, since
> that's all we're waiting for. It had general consensus agreement but
> failed because Aaron -1'd it since you weren't here. Now that you're
> back, I'm re-raising the question.
>
In general, this sounds like a reasonable approach. However ...
It looks to me like we've got solid release versions for:
+ commons-beanutils 1.6.1
+ commons-collections 2.1
+ commons-digester 1.5 (fixes a backwards incompatibility
in 1.4.1, release underway now)
+ commons-lang 1.0.1
+ commons-logging 1.0.3
+ commmons-validator 1.0.2
+ jakarta-oro 2.0.7
But don't we still have issues with *all* of the following?
- commons-dbcp
- commons-fileupload
- commons-pool
Martin, where are we on a final FileUpload release?
Note that, as a process issue, release votes are majority, not consensus:
http://jakarta.apache.org/site/decisions.html
so it would have been "legal" to do an RC2 release anyway, in spite of a
-1, if there were still a majority of +1s.
Also, it looks like we should finish deciding how to deal with Bugzilla
#18888 before an RC2 release.
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Craig's back, so I'm asking again...
Posted by Martin Cooper <ma...@apache.org>.
Oh, and before anyone asks, no, I'm not trying to hold back Struts 1.1
until JSF is ready. ;-)
On Sat, 26 Apr 2003, Martin Cooper wrote:
>
>
> On Sat, 26 Apr 2003, James Turner wrote:
>
> > Craig, we had a vote in your absence to do an RC2 release with the idea
> > that we could slipstream DBCP and Pool into the final release, since
> > that's all we're waiting for. It had general consensus agreement but
> > failed because Aaron -1'd it since you weren't here. Now that you're
> > back, I'm re-raising the question.
>
> I'm not Craig ;-) and I didn't vote last time around because Arron had
> already given his -1 by the time I caught up with the thread, but this
> time I'll be the first to chime in with a -1.
>
> In general, I disagree with having an RC (== Release Candidate) that is
> not actually a release candidate. If the distributed code is not the same,
> modulo the version number, as what we would ship as a Final release, then
> it's not an RC.
>
> In addition, we need a FileUpload release as well as Pool and DBCP. Some
> of the methods that Struts calls will be deprecated, so the Struts code
> will need to change. (I explained all this in a separate message a while
> ago.) That, in my opinion, has to happen before Struts 1.1 RC2.
>
> --
> Martin Cooper
>
>
> >
> > James Turner
> > Directory of Software Development, Benefit Systems, Inc.
> > Chair, COMDEX 2003 Strategic Open Source Track
> > turner@blackbear.com
> >
> > Author:
> > MySQL & JSP Web Applications: Data Driven Programming Using Tomcat
> > and MySQL
> > Struts Kick Start
> > Forthcoming:
> > JavaServer Faces Kick Start
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: struts-dev-help@jakarta.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Craig's back, so I'm asking again...
Posted by Ted Husted <hu...@apache.org>.
James Turner wrote:
> One of the biggest digs made against open source is that the developers
> have no commitment to release schedules, so you never know when things
> will be available.
Here's a story that describes the true nature of open source:
http://jakarta.apache.org/site/contributing.html
My perspective is this: if anyone wants 1.1 out sooner, then they can
dig in and make it happen. (And I'm not talking to James here, who's
kept the validator working for us, but to the list.)
If Struts 1.1 isn't happening fast enough for the corporate users, then
there aren't enough corporate users helping with the development of
Struts and its dependent packages.
Since I'm not an evangelist, I don't really care if other people use
Struts or not. It works for me, and I just try to share the wealth, best
I can.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
RE: Craig's back, so I'm asking again...
Posted by James Turner <tu...@blackbear.com>.
> -----Original Message-----
> From: Martin Cooper [mailto:martinc@apache.org]
> Sent: Saturday, April 26, 2003 6:01 PM
> To: Struts Developers List
> Cc: 'Craig R. McClanahan'
> Subject: Re: Craig's back, so I'm asking again...
>
> In general, I disagree with having an RC (== Release
> Candidate) that is not actually a release candidate. If the
> distributed code is not the same, modulo the version number,
> as what we would ship as a Final release, then it's not an RC.
*disheartened sigh*
Martin, I agree with you in principal, but I'm beginning to lose hope...
One of the biggest digs made against open source is that the developers
have no commitment to release schedules, so you never know when things
will be available. From my anecdotal experience, most of the
commercial/business Struts user community refuses to go to 1.1 until
there is a final release. This means that they are continuing to use
1.0, which has a LOT more warts on it than even a buggy 1.1 release
would, and 1.1 is in no way a buggy release.
As a Struts evangelist (one of a set, collect them all...), it's very
hard to recommend a framework with a "some day..." release date. And
with 1.1 basically frozen for more than a month now, there's a lot of
new work that's hanging fire.
I'm afraid I'm gonna have stick my stake in the sand at this point, and
say that if we don't get concrete-to-within-a-few-days estimates on when
the outstanding Commons packages are going to release, and if those days
aren't within a couple of weeks, we need to take a stand, release 1.1
with nightlies of those packages, and catch them up in a 1.11 or 1.2
release. Otherwise, the aforementioned scenario of JSF RI 1 shipping
before Struts 1.1 does will be a reality rather than a conspiracy
theory.
James
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Craig's back, so I'm asking again...
Posted by Martin Cooper <ma...@apache.org>.
On Sat, 26 Apr 2003, James Turner wrote:
> Craig, we had a vote in your absence to do an RC2 release with the idea
> that we could slipstream DBCP and Pool into the final release, since
> that's all we're waiting for. It had general consensus agreement but
> failed because Aaron -1'd it since you weren't here. Now that you're
> back, I'm re-raising the question.
I'm not Craig ;-) and I didn't vote last time around because Arron had
already given his -1 by the time I caught up with the thread, but this
time I'll be the first to chime in with a -1.
In general, I disagree with having an RC (== Release Candidate) that is
not actually a release candidate. If the distributed code is not the same,
modulo the version number, as what we would ship as a Final release, then
it's not an RC.
In addition, we need a FileUpload release as well as Pool and DBCP. Some
of the methods that Struts calls will be deprecated, so the Struts code
will need to change. (I explained all this in a separate message a while
ago.) That, in my opinion, has to happen before Struts 1.1 RC2.
--
Martin Cooper
>
> James Turner
> Directory of Software Development, Benefit Systems, Inc.
> Chair, COMDEX 2003 Strategic Open Source Track
> turner@blackbear.com
>
> Author:
> MySQL & JSP Web Applications: Data Driven Programming Using Tomcat
> and MySQL
> Struts Kick Start
> Forthcoming:
> JavaServer Faces Kick Start
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org