You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Nick Lesincki <nl...@yahoo.com> on 2003/08/05 21:31:41 UTC
RE: When is the next release?
It has been at least 1 month since question was asked
When is the next release?
Last msg said 1 month after 1.1 and a release manager
was required and some bug fixes would be out.
Nicolas
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: When is the next release?
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Mon, 11 Aug 2003, Ted Husted wrote:
> * I trimmed the containers to test against to Tomcat 3.3 and Tomcat 4.1,
> being the reigning References Implementations for our target platforms.
I'm fine with this for now, but I'd also like to sometime start
non-normative testing (i.e. failures wouldn't necessarily block a
Struts release) against Tomcat 5 at some point, to make sure we're
not building in things that are going to mess up in a Servlet 2.4 / JSP
2.0 container.
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: When is the next release?
Posted by David Graham <gr...@yahoo.com>.
I have problems with the Standard Release Criteria > Apply Patches
section. There are well over 100 enhancements in bugzilla, some with
patches. We shouldn't be forced to go through these before each release
and examine the patches. We have to decide if the enhancement is good for
Struts, then examine the patch, add the code sometimes in multiple places,
and test it. As you know, this can take a long time and is a significant
contribution by a committer. It takes far longer to apply a patch than it
does to create one.
I think it's more appropriate to let committers examine enhancements when
they get time and let them be committed or die in bugzilla as needed.
Forcing us to examine every patch will slow releases and take some of the
fun out of working on Struts.
David
--- Ted Husted <hu...@apache.org> wrote:
> I've posted a draft release plan. It's not linked but can be found here:
>
> http://jakarta.apache.org/struts/proposals/release-plan_1_2_0.html
>
> Since this is a transitional document, I'm not going to call for a vote
> on it this morning, but will do so later, depending on how the comments
> run.
>
> Points of note:
>
> * I set the roll-date for next Sunday, the 17th, which may be ambitious.
>
> If no one is burning to commit anything revolutionary right now, I'd be
> more comfortable with rolling this on the 24th.
>
> * Initially, the distribution would be announced on struts-dev and not
> posted to the public distribution directory. After voting on the Alpha
> version, we would then post it publicly and announce to the other lists.
>
> The vote could also promote the distribution to Beta or GA, as the
> Committers deem fit.
>
> * I've set this up as a boilerplate to outline what we need to do for an
>
> ongoing "point" release versus the initial "minor" release. In terms of
> Bugzilla resolutions, the document suggests that we do for the initial
> minor release (#.#.0) what we have always done. For any other point
> release, we wouldn't require that every ticket be resolved, but would
> still require that all showstoppers and tickets with patches be
> resolved.
>
> * Since this would be the initial minor release for the 1.2.x series,
> the "high bar" would apply.
>
> * I trimmed the containers to test against to Tomcat 3.3 and Tomcat 4.1,
>
> being the reigning References Implementations for our target platforms.
>
> * If anyone else wants to do the Release Manager thing for 1.2.0, feel
> free to chime in -- I'm not jealous =:0)
>
> -Ted.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-dev-help@jakarta.apache.org
>
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: When is the next release?
Posted by Ted Husted <hu...@apache.org>.
I've posted a draft release plan. It's not linked but can be found here:
http://jakarta.apache.org/struts/proposals/release-plan_1_2_0.html
Since this is a transitional document, I'm not going to call for a vote
on it this morning, but will do so later, depending on how the comments
run.
Points of note:
* I set the roll-date for next Sunday, the 17th, which may be ambitious.
If no one is burning to commit anything revolutionary right now, I'd be
more comfortable with rolling this on the 24th.
* Initially, the distribution would be announced on struts-dev and not
posted to the public distribution directory. After voting on the Alpha
version, we would then post it publicly and announce to the other lists.
The vote could also promote the distribution to Beta or GA, as the
Committers deem fit.
* I've set this up as a boilerplate to outline what we need to do for an
ongoing "point" release versus the initial "minor" release. In terms of
Bugzilla resolutions, the document suggests that we do for the initial
minor release (#.#.0) what we have always done. For any other point
release, we wouldn't require that every ticket be resolved, but would
still require that all showstoppers and tickets with patches be resolved.
* Since this would be the initial minor release for the 1.2.x series,
the "high bar" would apply.
* I trimmed the containers to test against to Tomcat 3.3 and Tomcat 4.1,
being the reigning References Implementations for our target platforms.
* If anyone else wants to do the Release Manager thing for 1.2.0, feel
free to chime in -- I'm not jealous =:0)
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: When is the next release?
Posted by Ted Husted <hu...@apache.org>.
Craig R. McClanahan wrote:
> Tomcat's 4.1 experience was that only every sixth release or so was voted
> GA, at least for the first several.
I think if you look at the various Betas and RCs most Jakarta products
go through, six would be the mode. So, this seems pretty typical.
> I think it's unlikely to pass a GA vote, simply because ripping out all
> the deprecated stuff is a fairly major amount of surgery, and we might
> have missed something. But we'll see.
Which is the beauty of this system. If it turns out to be GA after-all,
we just need to update the links. CVS remains the same.
> Absolutely. One missing detail in the plan, though, is whether we branch
> on each 1.2.x release. Tomcat doesn't and I don't see a reason to since
> we would probably never go back and try a 1.2.5.1 release to fix something
> in 1.2.5.
Agreed. The release scheme implies that you wouldn't reissue a release.
At most, you'd issue a patch based on the CVS tag. But more likely,
you'd fix 1.2.5 with 1.2.6, and demote 1.2.5 if there was a serious issue.
> Another thing Remy does for Tomcat (which I *really* appreciate) is keeps
> a running change log (summary, not detailed) in the release notes for each
> version. That way, everyone can get a quick summary of what's changed.
> I'd like this kind of thing to be part of the release manager's
> responsibilities.
Once upon a time, I did a lot of this when we were ramping up for a
milestone, but burned out during the 1.1 campaign. I agree that this is
important, and so will bring us current for 1.x -> 1.2.x.
I'm also thinking we should make a concerted effort to apply or discount
any outstanding patches developers have submitted. There's at least 21
of these now.
http://issues.apache.org/bugzilla/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=VERIFIED&email1=&emailtype1=substring&emailassigned_to1=1&email2=&emailtype2=substring&emailreporter2=1&bugidtype=include&bug_id=&changedin=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&product=Struts&short_desc=&short_desc_type=allwordssubstr&long_desc=&long_desc_type=allwordssubstr&bug_file_loc=&bug_file_loc_type=allwordssubstr&keywords=PatchAvailable&keywords_type=anywords&field0-0-0=noop&type0-0-0=noop&value0-0-0=&cmdtype=doit&order=Bug+Number
We may not have a fix for an outstanding issue yet, but we really should
honor any outstanding contributions.
> I'm a zero-relative guy at heart :-). My only concern is that people will
> assume 1.2.0 really means 1.2, but I'd be happy with either 1.2.0 or
> 1.2.1.
I think we should assume that people will make wrong assumptions no
matter what we do, so let's just start with zero, as Cantor intended. =:0)
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: When is the next release?
Posted by Ted Husted <hu...@apache.org>.
> Craig R. McClanahan wrote:
>> Another thing Remy does for Tomcat (which I *really* appreciate) is keeps
>> a running change log (summary, not detailed) in the release notes for
>> each
>> version. That way, everyone can get a quick summary of what's changed.
Ted Husted wrote:
> So, I'm working on one of these now for 1.1->1.2.0. I pulled the CVS log
> messages down in XML via Ant (with Don Brown's help), and I'm now
> looking at munging that into the format Tomcat is using.
I used Maven to generate a six-month changelog, snagged a couple of
other likely suspects, and integrated the XML doc into our own build.
Huge hack, but it seemed like the shortest route to get a summary
changelog up for this release.
The six-month changelog is huge, so I'm not going to post it to the site
right now. But, it's in CVS if anyone wants to check it out. We should
probably do the log in monthly chunks and hyperlink them together.
Next, I'll review this to see if we caught all the high-points in the
release notes.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: When is the next release?
Posted by Robert Leland <rl...@apache.org>.
Ted Husted wrote:
>
> I believe as soon as the next Validator ships, we could go ahead and
> roll 1.2.0. It may or may not be GA material, but we should get it out
> there where the community can decide.
>
I'll start working on it next weekend. I want to review the docs a
little to make sure they are up
to date then cut a release. There were a couple of good suggestions in
Bugzilla that David fielded
but those could wait for a 1.1.2 release.
> -Ted.
-Rob
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: [VOTE] 1.2.0 Release Plan
Posted by Joe Germuska <Jo...@Germuska.com>.
+ 1 on the release plan...
>Note that I've left room in the release plan for the idea of
>multiple managers. If someone were up for sheparding the tests,
>especially the example application testing, I'd welcome the help.
I may as well take this moment to fess up to my remedial status
trying to run the cactus tests in Ant (as opposed to Maven). I don't
want to commit my Maven/cactus work until the Ant tests pass too, and
they don't. They never have for me, so I'm sure it's just that I
haven't figured out the details of configuring the Ant environment.
(I can tell you that it's going to be a whole lot easier for everyone
in Maven!)
In the interest of moving that forward, I'll start another thread on
the subject...
Joe
--
Joe Germuska
Joe@Germuska.com
http://blog.germuska.com
"We want beef in dessert if we can get it there."
-- Betty Hogan, Director of New Product Development, National
Cattlemen's Beef Association
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: [VOTE] 1.2.0 Release Plan
Posted by Vic Cekvenich <ce...@basebeans.com>.
Ted Husted wrote:
. If someone were up for sheparding the tests, especially the
> example application testing,
If testing example apps, means not much more than see if the war files
work and browse it, I will do it. (of course some of them had problems
before, like tiles example, but not sure what, like broken links, but I
will test ). I would rather not learn Cactus, etc.
Tell me when to plan.
I might do it anyway, with a nightly build, and also test it in my bP,
that nothing is broken, and will send a mail to the dev list.
Is the nighly build very similar to 1.2 so some can happen now?
.V
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: [VOTE] 1.2.0 Release Plan
Posted by James Mitchell <jm...@apache.org>.
On Tue, 16 Dec 2003, Ted Husted wrote:
+1
> I've amended the date on the (now venerable) 1.2.0 release plan for this
> weekend.
>
> http://jakarta.apache.org/struts/proposals/release-plan_1_2_0.html
>
> I believe the release notes are in good shape now. I already marched
> through most of the stale 1.0/1.1 tickets, and can mop up the rest in
> short order. I imagine there will be a few patches that we can apply,
> but I've carved out some time to work on such.
>
> Note that I've left room in the release plan for the idea of multiple
> managers. If someone were up for sheparding the tests, especially the
> example application testing, I'd welcome the help. Someone else could
> also sign up for the final tag, roll, and announce part of the job. Of
> course, if everyone is busy, I'll be happy to muddle through on my own. :)
>
> Since this is a x.0 release, the plan calls for a majority vote.
>
> Here's my +1
>
> -Ted.
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-dev-help@jakarta.apache.org
>
>
--
James Mitchell
Software Developer / Struts Evangelist
http://www.struts-atlanta.org
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: [VOTE] 1.2.0 Release Plan
Posted by "Craig R. McClanahan" <cr...@apache.org>.
Quoting Martin Cooper <ma...@apache.org>:
> The issue isn't so much with voting on the relesae plan, but voting on the
> release itself. As you say, the HTTPD rules say that anyone can create a
> release. We're not HTTPD, though, and the Jakarta rules are different. As
> long as we're part of Jakarta, we need to abide by the Jakarta rules.
>
> Under "Decision Making", in the section on "Release Testing", is the
> following statement:
>
> "Majority approval is required before the release can be made."
> http://jakarta.apache.org/site/decisions.html
>
> So, we do need to vote on each and every release.
>
The Tomcat folks do indeed vote on every release -- they just do things in a
little different order:
* Post what amounts to a release candidate and
announce to a limited audience (dev and user
lists) asking for testing.
* Testing ensues ...
* Call a vote on the release, with the options
to call it alpha, beta, stable (that's fine
with me), or withdraw (if there was some
bad problem).
* Announce to the world and do the usual process
of distributing the bits.
The same approach would work for us, and IMHO meets the Jakarta requirements
with one additional wrinkle -- the Jakarta PMC needs the opportunity to vote on
releases as well, to be consistent with the current ASF reqirements.
+1 on the 1.2.0 release plan, by the way.
> --
> Martin Cooper
Craig
>
>
>
> On Tue, 16 Dec 2003, Ted Husted wrote:
>
> > With this proposal, I took a middle ground. The initial minor release
> > (x.x.0) in a series called for a vote on a plan, but a plan would be
> > optional for additional releases in the same series (1.2.1, 1.2.2, ...).
> > So, we wouldn't have to vote on a plan again until we get to 1.3.0 or
> > 2.0.0.
> >
> > The rationale is that starting a new series (1.2.0 versus 1.1.0) is a
> > decision upon which we should have a formal consensus. After that,
> > issuing additional point releases in the same series can be "business as
> > usual" .
> >
> > Of course, this is just a vote on the plan. Once we roll the release,
> > there would be another vote on whether to take that specific entity from
> > Alpha to Beta and/or General Availability. (Though, personally, I prefer
> > the more common "stable" designation to GA.)
> >
> > Of course, as the HTTPD guidelines point out, under the Apache License,
> > anyone can distribute a release of our codebase. It's just a matter of
> > whether it can be called "Struts" or not. :)
> >
> > -Ted,
> >
> > Martin Cooper wrote:
> > > +1
> > >
> > > I've added myself as an RM, since I'll be available to help. I can take
> on
> > > the tag, roll, sign and announce part, if you like.
> > >
> > > One thing I'd like to point out, because it came up in Commons, is that
> > > the HTTPD process and the Jakarta process are not 100% compatible. In
> > > particular, the Jakarta rules require a vote, while the HTTPD rules do
> > > not. I suspect that this vote may be sufficient, but I'll check when I
> get
> > > a chance.
> > >
> > > --
> > > Martin Cooper
> > >
> > >
> > > On Tue, 16 Dec 2003, Ted Husted wrote:
> > >
> > >
> > >>I've amended the date on the (now venerable) 1.2.0 release plan for this
> > >> weekend.
> > >>
> > >>http://jakarta.apache.org/struts/proposals/release-plan_1_2_0.html
> > >>
> > >>I believe the release notes are in good shape now. I already marched
> > >>through most of the stale 1.0/1.1 tickets, and can mop up the rest in
> > >>short order. I imagine there will be a few patches that we can apply,
> > >>but I've carved out some time to work on such.
> > >>
> > >>Note that I've left room in the release plan for the idea of multiple
> > >>managers. If someone were up for sheparding the tests, especially the
> > >>example application testing, I'd welcome the help. Someone else could
> > >>also sign up for the final tag, roll, and announce part of the job. Of
> > >>course, if everyone is busy, I'll be happy to muddle through on my own.
> :)
> > >>
> > >>Since this is a x.0 release, the plan calls for a majority vote.
> > >>
> > >>Here's my +1
> > >>
> > >>-Ted.
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>---------------------------------------------------------------------
> > >>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
> >
> >
>
> ---------------------------------------------------------------------
> 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: [VOTE] 1.2.0 Release Plan
Posted by Ted Husted <hu...@apache.org>.
Clarifying the voting guidelines is an active thread on the PMC list, so
we might just want to muddle along best we can for now. Regardless of
what we do for 1.2.1, we have called for a vote on a release plan for
1.2.0. The plan does call for a vote before classifying the Alpha as a
Beta or General Availability, so we would have the majority vote
mentioned in the current Jakarta guidelines.
And, AFAIK, what we are doing is compatible with what Tomcat is doing,
and Tomcat is also still under the Jakarta umbrella.
Of course, until we have our own PMC, we do need to give the Jakarta PMC
notice of the release, so as to make it a legal release of the
Foundation. But, we have already documented that in our own Release
Guidelines document. (Traditionally, what is published at the top-level
of Jakarta were guidelines that products could observe until they
documented their own guidelines, which is what we have been doing.)
Whether or not we should have our own PMC, which is to say petition to
become a top-level Apache project, is a topic that I would like to
discuss once 1.2.0 is released. But first things first :)
-Ted.
Martin Cooper wrote:
> The issue isn't so much with voting on the relesae plan, but voting on the
> release itself. As you say, the HTTPD rules say that anyone can create a
> release. We're not HTTPD, though, and the Jakarta rules are different. As
> long as we're part of Jakarta, we need to abide by the Jakarta rules.
>
> Under "Decision Making", in the section on "Release Testing", is the
> following statement:
>
> "Majority approval is required before the release can be made."
> http://jakarta.apache.org/site/decisions.html
>
> So, we do need to vote on each and every release.
>
> --
> Martin Cooper
>
>
>
> On Tue, 16 Dec 2003, Ted Husted wrote:
>
>
>>With this proposal, I took a middle ground. The initial minor release
>>(x.x.0) in a series called for a vote on a plan, but a plan would be
>>optional for additional releases in the same series (1.2.1, 1.2.2, ...).
>>So, we wouldn't have to vote on a plan again until we get to 1.3.0 or
>>2.0.0.
>>
>>The rationale is that starting a new series (1.2.0 versus 1.1.0) is a
>>decision upon which we should have a formal consensus. After that,
>>issuing additional point releases in the same series can be "business as
>>usual" .
>>
>>Of course, this is just a vote on the plan. Once we roll the release,
>>there would be another vote on whether to take that specific entity from
>>Alpha to Beta and/or General Availability. (Though, personally, I prefer
>>the more common "stable" designation to GA.)
>>
>>Of course, as the HTTPD guidelines point out, under the Apache License,
>>anyone can distribute a release of our codebase. It's just a matter of
>>whether it can be called "Struts" or not. :)
>>
>>-Ted,
>>
>>Martin Cooper wrote:
>>
>>>+1
>>>
>>>I've added myself as an RM, since I'll be available to help. I can take on
>>>the tag, roll, sign and announce part, if you like.
>>>
>>>One thing I'd like to point out, because it came up in Commons, is that
>>>the HTTPD process and the Jakarta process are not 100% compatible. In
>>>particular, the Jakarta rules require a vote, while the HTTPD rules do
>>>not. I suspect that this vote may be sufficient, but I'll check when I get
>>>a chance.
>>>
>>>--
>>>Martin Cooper
>>>
>>>
>>>On Tue, 16 Dec 2003, Ted Husted wrote:
>>>
>>>
>>>
>>>>I've amended the date on the (now venerable) 1.2.0 release plan for this
>>>> weekend.
>>>>
>>>>http://jakarta.apache.org/struts/proposals/release-plan_1_2_0.html
>>>>
>>>>I believe the release notes are in good shape now. I already marched
>>>>through most of the stale 1.0/1.1 tickets, and can mop up the rest in
>>>>short order. I imagine there will be a few patches that we can apply,
>>>>but I've carved out some time to work on such.
>>>>
>>>>Note that I've left room in the release plan for the idea of multiple
>>>>managers. If someone were up for sheparding the tests, especially the
>>>>example application testing, I'd welcome the help. Someone else could
>>>>also sign up for the final tag, roll, and announce part of the job. Of
>>>>course, if everyone is busy, I'll be happy to muddle through on my own. :)
>>>>
>>>>Since this is a x.0 release, the plan calls for a majority vote.
>>>>
>>>>Here's my +1
>>>>
>>>>-Ted.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>---------------------------------------------------------------------
>>>>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
>>
>>
>
>
> ---------------------------------------------------------------------
> 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: [VOTE] 1.2.0 Release Plan
Posted by Martin Cooper <ma...@apache.org>.
The issue isn't so much with voting on the relesae plan, but voting on the
release itself. As you say, the HTTPD rules say that anyone can create a
release. We're not HTTPD, though, and the Jakarta rules are different. As
long as we're part of Jakarta, we need to abide by the Jakarta rules.
Under "Decision Making", in the section on "Release Testing", is the
following statement:
"Majority approval is required before the release can be made."
http://jakarta.apache.org/site/decisions.html
So, we do need to vote on each and every release.
--
Martin Cooper
On Tue, 16 Dec 2003, Ted Husted wrote:
> With this proposal, I took a middle ground. The initial minor release
> (x.x.0) in a series called for a vote on a plan, but a plan would be
> optional for additional releases in the same series (1.2.1, 1.2.2, ...).
> So, we wouldn't have to vote on a plan again until we get to 1.3.0 or
> 2.0.0.
>
> The rationale is that starting a new series (1.2.0 versus 1.1.0) is a
> decision upon which we should have a formal consensus. After that,
> issuing additional point releases in the same series can be "business as
> usual" .
>
> Of course, this is just a vote on the plan. Once we roll the release,
> there would be another vote on whether to take that specific entity from
> Alpha to Beta and/or General Availability. (Though, personally, I prefer
> the more common "stable" designation to GA.)
>
> Of course, as the HTTPD guidelines point out, under the Apache License,
> anyone can distribute a release of our codebase. It's just a matter of
> whether it can be called "Struts" or not. :)
>
> -Ted,
>
> Martin Cooper wrote:
> > +1
> >
> > I've added myself as an RM, since I'll be available to help. I can take on
> > the tag, roll, sign and announce part, if you like.
> >
> > One thing I'd like to point out, because it came up in Commons, is that
> > the HTTPD process and the Jakarta process are not 100% compatible. In
> > particular, the Jakarta rules require a vote, while the HTTPD rules do
> > not. I suspect that this vote may be sufficient, but I'll check when I get
> > a chance.
> >
> > --
> > Martin Cooper
> >
> >
> > On Tue, 16 Dec 2003, Ted Husted wrote:
> >
> >
> >>I've amended the date on the (now venerable) 1.2.0 release plan for this
> >> weekend.
> >>
> >>http://jakarta.apache.org/struts/proposals/release-plan_1_2_0.html
> >>
> >>I believe the release notes are in good shape now. I already marched
> >>through most of the stale 1.0/1.1 tickets, and can mop up the rest in
> >>short order. I imagine there will be a few patches that we can apply,
> >>but I've carved out some time to work on such.
> >>
> >>Note that I've left room in the release plan for the idea of multiple
> >>managers. If someone were up for sheparding the tests, especially the
> >>example application testing, I'd welcome the help. Someone else could
> >>also sign up for the final tag, roll, and announce part of the job. Of
> >>course, if everyone is busy, I'll be happy to muddle through on my own. :)
> >>
> >>Since this is a x.0 release, the plan calls for a majority vote.
> >>
> >>Here's my +1
> >>
> >>-Ted.
> >>
> >>
> >>
> >>
> >>
> >>---------------------------------------------------------------------
> >>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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: [VOTE] 1.2.0 Release Plan
Posted by Ted Husted <hu...@apache.org>.
With this proposal, I took a middle ground. The initial minor release
(x.x.0) in a series called for a vote on a plan, but a plan would be
optional for additional releases in the same series (1.2.1, 1.2.2, ...).
So, we wouldn't have to vote on a plan again until we get to 1.3.0 or
2.0.0.
The rationale is that starting a new series (1.2.0 versus 1.1.0) is a
decision upon which we should have a formal consensus. After that,
issuing additional point releases in the same series can be "business as
usual" .
Of course, this is just a vote on the plan. Once we roll the release,
there would be another vote on whether to take that specific entity from
Alpha to Beta and/or General Availability. (Though, personally, I prefer
the more common "stable" designation to GA.)
Of course, as the HTTPD guidelines point out, under the Apache License,
anyone can distribute a release of our codebase. It's just a matter of
whether it can be called "Struts" or not. :)
-Ted,
Martin Cooper wrote:
> +1
>
> I've added myself as an RM, since I'll be available to help. I can take on
> the tag, roll, sign and announce part, if you like.
>
> One thing I'd like to point out, because it came up in Commons, is that
> the HTTPD process and the Jakarta process are not 100% compatible. In
> particular, the Jakarta rules require a vote, while the HTTPD rules do
> not. I suspect that this vote may be sufficient, but I'll check when I get
> a chance.
>
> --
> Martin Cooper
>
>
> On Tue, 16 Dec 2003, Ted Husted wrote:
>
>
>>I've amended the date on the (now venerable) 1.2.0 release plan for this
>> weekend.
>>
>>http://jakarta.apache.org/struts/proposals/release-plan_1_2_0.html
>>
>>I believe the release notes are in good shape now. I already marched
>>through most of the stale 1.0/1.1 tickets, and can mop up the rest in
>>short order. I imagine there will be a few patches that we can apply,
>>but I've carved out some time to work on such.
>>
>>Note that I've left room in the release plan for the idea of multiple
>>managers. If someone were up for sheparding the tests, especially the
>>example application testing, I'd welcome the help. Someone else could
>>also sign up for the final tag, roll, and announce part of the job. Of
>>course, if everyone is busy, I'll be happy to muddle through on my own. :)
>>
>>Since this is a x.0 release, the plan calls for a majority vote.
>>
>>Here's my +1
>>
>>-Ted.
>>
>>
>>
>>
>>
>>---------------------------------------------------------------------
>>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: [VOTE] 1.2.0 Release Plan
Posted by Martin Cooper <ma...@apache.org>.
+1
I've added myself as an RM, since I'll be available to help. I can take on
the tag, roll, sign and announce part, if you like.
One thing I'd like to point out, because it came up in Commons, is that
the HTTPD process and the Jakarta process are not 100% compatible. In
particular, the Jakarta rules require a vote, while the HTTPD rules do
not. I suspect that this vote may be sufficient, but I'll check when I get
a chance.
--
Martin Cooper
On Tue, 16 Dec 2003, Ted Husted wrote:
> I've amended the date on the (now venerable) 1.2.0 release plan for this
> weekend.
>
> http://jakarta.apache.org/struts/proposals/release-plan_1_2_0.html
>
> I believe the release notes are in good shape now. I already marched
> through most of the stale 1.0/1.1 tickets, and can mop up the rest in
> short order. I imagine there will be a few patches that we can apply,
> but I've carved out some time to work on such.
>
> Note that I've left room in the release plan for the idea of multiple
> managers. If someone were up for sheparding the tests, especially the
> example application testing, I'd welcome the help. Someone else could
> also sign up for the final tag, roll, and announce part of the job. Of
> course, if everyone is busy, I'll be happy to muddle through on my own. :)
>
> Since this is a x.0 release, the plan calls for a majority vote.
>
> Here's my +1
>
> -Ted.
>
>
>
>
>
> ---------------------------------------------------------------------
> 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: [VOTE] 1.2.0 Release Plan
Posted by Martin Cooper <ma...@apache.org>.
I haven't had a chance to catch up completely, but the outage this weekend
suggests an after-Christmas 1.2.0 release, unfortunately - at least, if I
need to be involved. (If not, great - go for it!)
--
Martin Cooper
On Sun, 21 Dec 2003, Ted Husted wrote:
> OK, here's what we have
>
> * Release notes updated
> * Issues w/o solutions marked LATER
> * Webapps tested on TC 4.1 (one issue)
> * JUnit tests run
>
> In the Validator example, we're suppose to be able to change selected
> validations for a county just by overriding a form in a formset. This
> doesn't work unless you respecify the entire formset. I fixed the
> example, but we should decide if this is suppose to be a supported
> feature or not.
>
> Here's what we don't have
>
> * Webapps tests on TC 3.3a (next)
> * Patches/fixes applied for 11 issues <http://tinyurl.com/ysx3x>
> * Cactus tests run (under Ant)
>
> I can't get Cactus running under Ant either, though Joe says they run
> under Maven.
>
> If the Cactus tests are truly broken under Ant:
>
> Do we want to call that a showstopper?
>
> If so, do we want to workaround that by taking the Cactus tests out
> of the buildfile for now, as we are moving to Maven anyway, and have Joe
> apply his Maven-Cactus patch.
>
> I could apply the patches sometime this week, but I'm leary of doing so
> when I can't get the Cactus tests to run on my own.
>
> If we resolve the Cactus thing quickly, do we want to release what we
> have as 1.2.0 (w/o the 11 patches), with the intention of rolling 1.2.1
> in January, or wait and do this after Christmas?
>
> -Ted.
>
>
>
>
> ---------------------------------------------------------------------
> 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: [VOTE] 1.2.0 Release Plan
Posted by Vic Cekvenich <ce...@basebeans.com>.
>I am now testing nightly and sample wars for what it's worth.
All wars work (once over lightly).
Somone did a nice job on localizing validation war.
bP works (which uses jstl 1.1, struts menu 2.1, etc.)
-Validation example complains in console about <formset not terminated
at end of file in validation.xml, and that tag it's not terminated.
-I wish most excetions were logged w/ e.getCuase() and not the entire
trace to fill up the console.
-Also Tomcat complains about formbeans not implementing seriaizable
marker for sesion scoped beans. (My baseBens does mark it as
seriazable... it's not. To me, that is a Tomcat bug, it should just be a
low level info log, becuase Resin does not care. Serializing beans for
fail over in container is not a good idea imo, DAO's can do it nicer
outside of the container's limitation)
So one minor error, <formset in valdation example
.V
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: [VOTE] 1.2.0 Release Plan
Posted by Vic Cekvenich <Ce...@baseBeans.com>.
Robert Leland wrote:
> Ted Husted wrote:
>
>> OK, here's what we have
>
>
>
>
> I would say release, we are using a x.y.z numbering scheme.
> Noteing in the limited release that this should be considered an Alpha
> until further testing says otherwise. Also to ask others not to announce
> this on other lists
> until it has been voted Beta/GA or better.
<Snip>
Side effect is that this is a great way to introduce 1.2.0 to users as
... it's released like Tomcat releases, but not really designated, and
not released like 1.1 was with beta, rc1....
I am now testing nightly and sample wars for what it's worth.
.V
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: [VOTE] 1.2.0 Release Plan
Posted by Joe Germuska <Jo...@Germuska.com>.
At 9:37 AM -0500 2/20/04, Ted Husted wrote:
>Assuming it was all right with everyone, I'm setting the freeze date
>for 1.2.0 for tomorrow (Saturday) night.
>
>I'm updating the release plan. There are still a lot of enhancement
>patches that we haven't applied, but I think those can wait for
>later in the 1.2.x series. I do intend to start marching down that
>list and either accepting or declining whatever patches people have
>submitted. So, I'm commenting out that section for the purpose of
>this release.
>
>All the other criteria have been met, and I believe we are ready to go.
>
>Martin, would you be able to take it from there, or is there any
>thing else I can do?
How do we relate the contrib packages to the release? Do we consider
them part of the release? When I made a change to the Javascript tag
class, and dealt with the struts-el ripples, I found that at the
time, the EL tests weren't building against the nightly build because
they imported ApplicationConfig, which has been removed. I fixed
that, but it made me wonder about this general question.
I don't want to hold things up at all, but I'm wondering if we want
to do at least a little checking of contrib packages against official
Struts releases? We could set this as a future goal to avoid
delaying 1.2.0, and maybe it's not even a goal -- but I thought I'd
ask.
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: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: [VOTE] 1.2.0 Release Plan
Posted by Ted Husted <hu...@apache.org>.
> contrib
Personally, I've been defining what is released by what is generated by the release target. :)
For Struts 1.1, Struts-El was released coincident with the Struts 1.1 release, but they were separate events. If someone wants to also roll a struts-el release, or struts-jsf release, please proceed. But I wouldn't feel qualified to do that myself (since I'm not a user of those packages).
Moving past 1.2.0, we might want to create a "opt" or "optional" products with their own release cycles, such as struts-opt-el, struts-opt-jsf, and struts-opt-taglib (for the rest). These could be their own Maven artifacts, each dependant on the struts-core project (being what is under share now).
Likewise, we might want to setup a struts-apps product and distribute the bundled applications as artifacts of that.
> dependencies
If there are new releases of some of our dependencies, then we should move to those. AFIAC, this should happen as soon as anyone is aware of a new final release.
> ASL 2.0
If someone wants to switch the licenses now, please feel free. But it's not something I would have time to do myself right now.
> Cactus
I've never gotten the Cactus tests to run, so I don't even try anymore. If they aren't running, and no one can fix them, then we should take them out.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: [VOTE] 1.2.0 Release Plan
Posted by Joe Germuska <Jo...@Germuska.com>.
At 1:49 PM -0600 2/20/04, Joe Germuska wrote:
>> > Just a few things:
>>>
>>> * What about the new Apache license? Technically, it doesn't need to
>>> change if we release before March 1st, but we're mighty close to that,
>>> so
>> > perhaps we should switch now?
>
>+1 from me too; wasn't someone offering to do it a few weeks ago?
I should amend this: + 0 from me; I don't have time to do it now, and
probably won't soon enough that I'd want to delay 1.2.0 until it gets
done.
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: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
RE: [VOTE] 1.2.0 Release Plan
Posted by Martin Cooper <ma...@apache.org>.
> -----Original Message-----
> From: Joe Germuska [mailto:Joe@Germuska.com]
> Sent: Friday, February 20, 2004 11:50 AM
> To: Struts Developers List
> Subject: Re: [VOTE] 1.2.0 Release Plan
>
>
> > > Just a few things:
> >>
> >> * What about the new Apache license? Technically, it doesn't need to
> >> change if we release before March 1st, but we're mighty close to that,
> >> so
> > > perhaps we should switch now?
>
> +1 from me too; wasn't someone offering to do it a few weeks ago?
>
> >At this point I don't see any reason to ever build against commons
> >nightlies unless we're using some unreleased feature.
>
> +1 on this as a baseline -- only depend on nightlies where necessary,
> not as a matter of course.
>
> > > Several of the Commons components
> >> we
> >> depend on have released since we last did, so we may want to
> update the
> >> versions in our dependency list.
> >
> >Collections is a particularly ugly situation. Do we upgrade to 3.0 and
> >break existing Struts apps requiring 2.x? Or, do we stay at 2.x
> and break
> > apps needing 3.0?
>
> I missed the details of this Collections change and its
> incompatibility, but I don't see why we'd upgrade to 3.0 unless we
> need it: same as with nightlies. Are there bugfixes rolled into 3
> along with the incompatibilities? I'd say we either make a
> collections-2 branch that has bugfixes but maintains compatibility,
> or pull what we need back into Struts. Without knowing the details,
> it sounds like a serious mistake/judgment error was made in releasing
> 3.0, but we shouldn't subject all Struts users to the consequences.
>
> > > * The Cactus tests won't run for me, for some reason. When I
> start the
> >> tests, everything looks fine as it starts up, but then it just sits
> >> there
> >> doing nothing. They used to work, but I can't recall what I might have
> >> changed to break it. Anyone have any ideas? Obviously, I don't want to
> > > create a release and not be able to run the tests!
>
> I was able to run the ant/Tomcat 4.0 tests up to the point where they
> always fail for me:
> org.apache.struts.taglib.bean.TestCookieTag.testCookieTagNameMultiple
> -- I have to assume this is some kind of local configuration problem,
> but I'm not hanging. One day I hope to have time to figure out the
> problem, but I'm far from a Cactus expert.
I don't get that far. The problem I have is not that the tests fail, but
that they do not run at all. After I invoke the target, everything seems to
start up OK, but then it just sits there doing nothing. I'd really like to
get past that point, if anyone has any ideas...
--
Martin Cooper
>
> (Has anyone tried running the Struts cactus tests with Maven? I had
> gotten it to the point where most of the tests passed, and the ones
> that didn't I suspected were similar to my Ant/Cactus failures --
> something local, not something in the code.)
>
> 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: 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: [VOTE] 1.2.0 Release Plan
Posted by Joe Germuska <Jo...@Germuska.com>.
> > Just a few things:
>>
>> * What about the new Apache license? Technically, it doesn't need to
>> change if we release before March 1st, but we're mighty close to that,
>> so
> > perhaps we should switch now?
+1 from me too; wasn't someone offering to do it a few weeks ago?
>At this point I don't see any reason to ever build against commons
>nightlies unless we're using some unreleased feature.
+1 on this as a baseline -- only depend on nightlies where necessary,
not as a matter of course.
> > Several of the Commons components
>> we
>> depend on have released since we last did, so we may want to update the
>> versions in our dependency list.
>
>Collections is a particularly ugly situation. Do we upgrade to 3.0 and
>break existing Struts apps requiring 2.x? Or, do we stay at 2.x and break
> apps needing 3.0?
I missed the details of this Collections change and its
incompatibility, but I don't see why we'd upgrade to 3.0 unless we
need it: same as with nightlies. Are there bugfixes rolled into 3
along with the incompatibilities? I'd say we either make a
collections-2 branch that has bugfixes but maintains compatibility,
or pull what we need back into Struts. Without knowing the details,
it sounds like a serious mistake/judgment error was made in releasing
3.0, but we shouldn't subject all Struts users to the consequences.
> > * The Cactus tests won't run for me, for some reason. When I start the
>> tests, everything looks fine as it starts up, but then it just sits
>> there
>> doing nothing. They used to work, but I can't recall what I might have
>> changed to break it. Anyone have any ideas? Obviously, I don't want to
> > create a release and not be able to run the tests!
I was able to run the ant/Tomcat 4.0 tests up to the point where they
always fail for me:
org.apache.struts.taglib.bean.TestCookieTag.testCookieTagNameMultiple
-- I have to assume this is some kind of local configuration problem,
but I'm not hanging. One day I hope to have time to figure out the
problem, but I'm far from a Cactus expert.
(Has anyone tried running the Struts cactus tests with Maven? I had
gotten it to the point where most of the tests passed, and the ones
that didn't I suspected were similar to my Ant/Cactus failures --
something local, not something in the code.)
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: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: [VOTE] 1.2.0 Release Plan
Posted by David Graham <gr...@yahoo.com>.
--- Martin Cooper <ma...@apache.org> wrote:
> On Fri, 20 Feb 2004, Ted Husted wrote:
>
> > Assuming it was all right with everyone, I'm setting the freeze date
> for 1.2.0 for tomorrow (Saturday) night.
> >
> > I'm updating the release plan. There are still a lot of enhancement
> patches that we haven't applied, but I think those can wait for later in
> the 1.2.x series. I do intend to start marching down that list and
> either accepting or declining whatever patches people have submitted.
> So, I'm commenting out that section for the purpose of this release.
> >
> > All the other criteria have been met, and I believe we are ready to
> go.
> >
> > Martin, would you be able to take it from there, or is there any thing
> else I can do?
>
> Just a few things:
>
> * What about the new Apache license? Technically, it doesn't need to
> change if we release before March 1st, but we're mighty close to that,
> so
> perhaps we should switch now?
+1
>
> * There was a brief discussion not too long ago about whether we should
> be
> building this release against released versions of Commons components or
> the nighlies. Since, in theory at least, this release could be promoted
> to
> a Final release, I assume the former?
At this point I don't see any reason to ever build against commons
nightlies unless we're using some unreleased feature. IMO, Struts
shouldn't use unreleased commons features because we'll end up in a 1.1
situation where we're waiting for commons releases. The exception would
be for alpha releases like Validator where it only needs testing before
getting a GA label.
> Several of the Commons components
> we
> depend on have released since we last did, so we may want to update the
> versions in our dependency list.
Collections is a particularly ugly situation. Do we upgrade to 3.0 and
break existing Struts apps requiring 2.x? Or, do we stay at 2.x and break
apps needing 3.0?
David
>
> * The Cactus tests won't run for me, for some reason. When I start the
> tests, everything looks fine as it starts up, but then it just sits
> there
> doing nothing. They used to work, but I can't recall what I might have
> changed to break it. Anyone have any ideas? Obviously, I don't want to
> create a release and not be able to run the tests!
>
> --
> Martin Cooper
>
>
> >
> > -Ted.
> >
> >
> >
> > ---------------------------------------------------------------------
> > 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
>
__________________________________
Do you Yahoo!?
Yahoo! Mail SpamGuard - Read only the mail you want.
http://antispam.yahoo.com/tools
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: [VOTE] 1.2.0 Release Plan
Posted by Martin Cooper <ma...@apache.org>.
On Fri, 20 Feb 2004, Ted Husted wrote:
> Assuming it was all right with everyone, I'm setting the freeze date for 1.2.0 for tomorrow (Saturday) night.
>
> I'm updating the release plan. There are still a lot of enhancement patches that we haven't applied, but I think those can wait for later in the 1.2.x series. I do intend to start marching down that list and either accepting or declining whatever patches people have submitted. So, I'm commenting out that section for the purpose of this release.
>
> All the other criteria have been met, and I believe we are ready to go.
>
> Martin, would you be able to take it from there, or is there any thing else I can do?
Just a few things:
* What about the new Apache license? Technically, it doesn't need to
change if we release before March 1st, but we're mighty close to that, so
perhaps we should switch now?
* There was a brief discussion not too long ago about whether we should be
building this release against released versions of Commons components or
the nighlies. Since, in theory at least, this release could be promoted to
a Final release, I assume the former? Several of the Commons components we
depend on have released since we last did, so we may want to update the
versions in our dependency list.
* The Cactus tests won't run for me, for some reason. When I start the
tests, everything looks fine as it starts up, but then it just sits there
doing nothing. They used to work, but I can't recall what I might have
changed to break it. Anyone have any ideas? Obviously, I don't want to
create a release and not be able to run the tests!
--
Martin Cooper
>
> -Ted.
>
>
>
> ---------------------------------------------------------------------
> 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: [VOTE] 1.2.0 Release Plan
Posted by Ted Husted <hu...@apache.org>.
Assuming it was all right with everyone, I'm setting the freeze date for 1.2.0 for tomorrow (Saturday) night.
I'm updating the release plan. There are still a lot of enhancement patches that we haven't applied, but I think those can wait for later in the 1.2.x series. I do intend to start marching down that list and either accepting or declining whatever patches people have submitted. So, I'm commenting out that section for the purpose of this release.
All the other criteria have been met, and I believe we are ready to go.
Martin, would you be able to take it from there, or is there any thing else I can do?
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: [VOTE] 1.2.0 Release Plan
Posted by James Mitchell <jm...@apache.org>.
On Wed, 24 Dec 2003, Joe Germuska wrote:
> At 9:38 AM -0500 12/22/03, Robert Leland wrote:
> >I believe Joe said though all unit test ran they **didn't** all
> >pass, I believe it was like 66%
> >passed.
>
> Hi, all... I've been at my in-laws for the holidays and have
> intermittent net access.
>
> I turned out my major ant/cactus problem was that Ant was using JUnit
> 3.7 and many of the tests use a version of assertEquals that was
> added in 3.8; the error messages weren't making it really clear, but
> a little sleuthing turned it up. So yesterday using Ant I was
> passing all but the testMultiple method in TestCookieTag -- one out
> of nearly 2000 methods. I'm running the tests again based on today's
> CVS Head, although I'm pretty sure it was only docs that have changed
> since my last update.
A while back, I committed some changes to exclude 3 particular tests from
the suite because of the (still unresolved) issues with the cactus wrapper
class(es) or out configuration of them (still don't know which is the
case).
>From Ant, the tests are passing (100%) on both of my Linux boxes
(Mandrake and Redhat), but I'm having issues with my laptop (XP Pro).
Anyway, just thought I'd throw in my $.02. Have a great
rest-of-the-holidays!!!
>
> Since I didn't make any changes to the class tested by that failure,
> I'm going to take this as the threshold and soon, I'll start checking
> in my changes to run tests under maven -- although not right this
> minute, and I'm not sure I'll do it until I get back home over the
> weekend; we'll see how things go.
>
> Running the tests under Maven was better than 66%; it was nearly 80%
> of classes passing cleanly, and only scattered methods through the
> others which have to do with cookies -- that consistency makes me
> pretty sure it's a config problem.
>
> Happy holidays to everyone; I'll be online again before I get back
> home, but only intermittently.
>
> Joe
--
James Mitchell
Software Developer / Struts Evangelist
http://www.struts-atlanta.org
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: [VOTE] 1.2.0 Release Plan
Posted by Joe Germuska <Jo...@Germuska.com>.
At 9:38 AM -0500 12/22/03, Robert Leland wrote:
>I believe Joe said though all unit test ran they **didn't** all
>pass, I believe it was like 66%
>passed.
Hi, all... I've been at my in-laws for the holidays and have
intermittent net access.
I turned out my major ant/cactus problem was that Ant was using JUnit
3.7 and many of the tests use a version of assertEquals that was
added in 3.8; the error messages weren't making it really clear, but
a little sleuthing turned it up. So yesterday using Ant I was
passing all but the testMultiple method in TestCookieTag -- one out
of nearly 2000 methods. I'm running the tests again based on today's
CVS Head, although I'm pretty sure it was only docs that have changed
since my last update.
Since I didn't make any changes to the class tested by that failure,
I'm going to take this as the threshold and soon, I'll start checking
in my changes to run tests under maven -- although not right this
minute, and I'm not sure I'll do it until I get back home over the
weekend; we'll see how things go.
Running the tests under Maven was better than 66%; it was nearly 80%
of classes passing cleanly, and only scattered methods through the
others which have to do with cookies -- that consistency makes me
pretty sure it's a config problem.
Happy holidays to everyone; I'll be online again before I get back
home, but only intermittently.
Joe
--
Joe Germuska
Joe@Germuska.com
http://blog.germuska.com
"We want beef in dessert if we can get it there."
-- Betty Hogan, Director of New Product Development, National
Cattlemen's Beef Association
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: [VOTE] 1.2.0 Release Plan
Posted by Robert Leland <rl...@apache.org>.
Ted Husted wrote:
> OK, here's what we have
I would say release, we are using a x.y.z numbering scheme.
Noteing in the limited release that this should be considered an Alpha
until further testing says otherwise. Also to ask others not to announce
this on other lists
until it has been voted Beta/GA or better.
I believe Joe said though all unit test ran they **didn't** all pass, I
believe it was like 66%
passed.
As an aside on the unit tests, I pulled all other Struts releases CVS,
1.1 Beta 2, RC 1, RC2
and ran our current unit tests against the source and they all failed at
some point.
That was using the same version of cactus used to test 1.2.0
-Rob
>
> * Release notes updated
> * Issues w/o solutions marked LATER
> * Webapps tested on TC 4.1 (one issue)
> * JUnit tests run
>
> In the Validator example, we're suppose to be able to change selected
> validations for a county just by overriding a form in a formset. This
> doesn't work unless you respecify the entire formset. I fixed the
> example, but we should decide if this is suppose to be a supported
> feature or not.
>
> Here's what we don't have
>
> * Webapps tests on TC 3.3a (next)
> * Patches/fixes applied for 11 issues <http://tinyurl.com/ysx3x>
> * Cactus tests run (under Ant)
>
> I can't get Cactus running under Ant either, though Joe says they run
> under Maven.
>
> If the Cactus tests are truly broken under Ant:
>
> Do we want to call that a showstopper?
>
> If so, do we want to workaround that by taking the Cactus tests
> out of the buildfile for now, as we are moving to Maven anyway, and
> have Joe apply his Maven-Cactus patch.
>
> I could apply the patches sometime this week, but I'm leary of doing so
> when I can't get the Cactus tests to run on my own.
>
> If we resolve the Cactus thing quickly, do we want to release what we
> have as 1.2.0 (w/o the 11 patches), with the intention of rolling
> 1.2.1 in January, or wait and do this after Christmas?
>
> -Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: [VOTE] 1.2.0 Release Plan
Posted by Ted Husted <hu...@apache.org>.
OK, here's what we have
* Release notes updated
* Issues w/o solutions marked LATER
* Webapps tested on TC 4.1 (one issue)
* JUnit tests run
In the Validator example, we're suppose to be able to change selected
validations for a county just by overriding a form in a formset. This
doesn't work unless you respecify the entire formset. I fixed the
example, but we should decide if this is suppose to be a supported
feature or not.
Here's what we don't have
* Webapps tests on TC 3.3a (next)
* Patches/fixes applied for 11 issues <http://tinyurl.com/ysx3x>
* Cactus tests run (under Ant)
I can't get Cactus running under Ant either, though Joe says they run
under Maven.
If the Cactus tests are truly broken under Ant:
Do we want to call that a showstopper?
If so, do we want to workaround that by taking the Cactus tests out
of the buildfile for now, as we are moving to Maven anyway, and have Joe
apply his Maven-Cactus patch.
I could apply the patches sometime this week, but I'm leary of doing so
when I can't get the Cactus tests to run on my own.
If we resolve the Cactus thing quickly, do we want to release what we
have as 1.2.0 (w/o the 11 patches), with the intention of rolling 1.2.1
in January, or wait and do this after Christmas?
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Post 1.2.0 [was 1.2.0 Release Plan]
Posted by Ted Husted <hu...@apache.org>.
David Graham wrote:
> --- Ted Husted <hu...@apache.org> wrote:
>
>>So, there were a few more outstanding reports that I thought we would
>>have.
>>
>>http://tinyurl.com/ysx3x
>
>
> Notice that 12 of the 29 bugs are custom tag related proving once again
> how badly we need to move them into their own distro.
Post 1.2.0, I'd like to look at revamping the website (keeping Maven in
mind of course) to separate the "core" documentation from the "taglib"
documentation (which is mainly the Developer Guides anyway). We should
probably add an area for "contrib" as well. (A better name for "contrib"
might be "opt", as in optional components.)
Essentially, we would start looking like Turbine or Jakarta itself,
where there is a portal page with links to various sub-projects. (Or in
our case, sub-sub-projects.)
One question would be whether core, taglibs, contrib, and site should
each have their own repository, so instead of just jakarta-struts, we'd
have jakarta-struts-core, jakarta-struts-taglib, jakarta-struts-apps,
jakarta-struts-opt (fka "contrib"), and jakarta-struts-site.
Obviously, before actually doing that, we should first decide if it's
time to apply for TLP status. (I believe Martin plans to post something
once 1.2.0 rolls.) But regardless of whether the repositories are styled
jakarta-struts-* or apache-struts-*, we can decide if we would want
these repositories or not.
There are a few advantages to separate repos:
(1) Each repository can have it own set of Committers
(2) Bandwidth is conserved for developers who are not interested in
every area
(3) It plays well with Maven
and disadvantages as well:
(1) We'd have to do the work to make the change
(2) We'd have to add Committers to more than one repo to give them
access to everything
(3) If you're working on everything, you'd have to make more than one
checkout to stay current with everything
An alternative would be to keep one repository, but to organize it so
that each area has a top-level directory.
Of course, we can start revamping the website before committing to any
repository changes, just to see how it would look.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: [VOTE] 1.2.0 Release Plan
Posted by David Graham <gr...@yahoo.com>.
--- Ted Husted <hu...@apache.org> wrote:
> So, there were a few more outstanding reports that I thought we would
> have.
>
> http://tinyurl.com/ysx3x
Notice that 12 of the 29 bugs are custom tag related proving once again
how badly we need to move them into their own distro.
>
> Six have patches, which I will try to apply tomorrow. Most of the others
>
> are reports about problems I may not know how to fix.
>
> I can thing of four ways to deal with these:
>
> (1) mark reports without proposed solutions "enhancements"
IMO, we shouldn't start making up new definitions of "enhancement" just to
accomodate our release schedule.
> (2) mark unresolved problem reports LATER (like before)
+1 on marking as LATER.
> (3) change the release plan so we can leave them open
> (4) forgo the release indefinitely
>
> On a related topic, would anyone call any of these "showstoppers".
No, I think we can release as planned.
David
>
> -Ted.
>
> Ted Husted wrote:
> > I've amended the date on the (now venerable) 1.2.0 release plan for
> this
> > weekend.
> >
> > http://jakarta.apache.org/struts/proposals/release-plan_1_2_0.html
> >
> > I believe the release notes are in good shape now. I already marched
> > through most of the stale 1.0/1.1 tickets, and can mop up the rest in
> > short order. I imagine there will be a few patches that we can apply,
> > but I've carved out some time to work on such.
> >
> > Note that I've left room in the release plan for the idea of multiple
> > managers. If someone were up for sheparding the tests, especially the
> > example application testing, I'd welcome the help. Someone else could
> > also sign up for the final tag, roll, and announce part of the job. Of
>
> > course, if everyone is busy, I'll be happy to muddle through on my
> own. :)
> >
> > Since this is a x.0 release, the plan calls for a majority vote.
> >
> > Here's my +1
> >
> > -Ted.
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-dev-help@jakarta.apache.org
>
__________________________________
Do you Yahoo!?
Free Pop-Up Blocker - Get it now
http://companion.yahoo.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: [VOTE] 1.2.0 Release Plan
Posted by Ted Husted <hu...@apache.org>.
So, there were a few more outstanding reports that I thought we would have.
http://tinyurl.com/ysx3x
Six have patches, which I will try to apply tomorrow. Most of the others
are reports about problems I may not know how to fix.
I can thing of four ways to deal with these:
(1) mark reports without proposed solutions "enhancements"
(2) mark unresolved problem reports LATER (like before)
(3) change the release plan so we can leave them open
(4) forgo the release indefinitely
On a related topic, would anyone call any of these "showstoppers".
-Ted.
Ted Husted wrote:
> I've amended the date on the (now venerable) 1.2.0 release plan for this
> weekend.
>
> http://jakarta.apache.org/struts/proposals/release-plan_1_2_0.html
>
> I believe the release notes are in good shape now. I already marched
> through most of the stale 1.0/1.1 tickets, and can mop up the rest in
> short order. I imagine there will be a few patches that we can apply,
> but I've carved out some time to work on such.
>
> Note that I've left room in the release plan for the idea of multiple
> managers. If someone were up for sheparding the tests, especially the
> example application testing, I'd welcome the help. Someone else could
> also sign up for the final tag, roll, and announce part of the job. Of
> course, if everyone is busy, I'll be happy to muddle through on my own. :)
>
> Since this is a x.0 release, the plan calls for a majority vote.
>
> Here's my +1
>
> -Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: [VOTE] 1.2.0 Release Plan
Posted by David Graham <gr...@yahoo.com>.
+1
David
--- Ted Husted <hu...@apache.org> wrote:
> I've amended the date on the (now venerable) 1.2.0 release plan for this
>
> weekend.
>
> http://jakarta.apache.org/struts/proposals/release-plan_1_2_0.html
>
> I believe the release notes are in good shape now. I already marched
> through most of the stale 1.0/1.1 tickets, and can mop up the rest in
> short order. I imagine there will be a few patches that we can apply,
> but I've carved out some time to work on such.
>
> Note that I've left room in the release plan for the idea of multiple
> managers. If someone were up for sheparding the tests, especially the
> example application testing, I'd welcome the help. Someone else could
> also sign up for the final tag, roll, and announce part of the job. Of
> course, if everyone is busy, I'll be happy to muddle through on my own.
> :)
>
> Since this is a x.0 release, the plan calls for a majority vote.
>
> Here's my +1
>
> -Ted.
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-dev-help@jakarta.apache.org
>
__________________________________
Do you Yahoo!?
Free Pop-Up Blocker - Get it now
http://companion.yahoo.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
[VOTE] 1.2.0 Release Plan
Posted by Ted Husted <hu...@apache.org>.
I've amended the date on the (now venerable) 1.2.0 release plan for this
weekend.
http://jakarta.apache.org/struts/proposals/release-plan_1_2_0.html
I believe the release notes are in good shape now. I already marched
through most of the stale 1.0/1.1 tickets, and can mop up the rest in
short order. I imagine there will be a few patches that we can apply,
but I've carved out some time to work on such.
Note that I've left room in the release plan for the idea of multiple
managers. If someone were up for sheparding the tests, especially the
example application testing, I'd welcome the help. Someone else could
also sign up for the final tag, roll, and announce part of the job. Of
course, if everyone is busy, I'll be happy to muddle through on my own. :)
Since this is a x.0 release, the plan calls for a majority vote.
Here's my +1
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: When is the next release?
Posted by Ted Husted <hu...@apache.org>.
I'll be out of town over the weekend and may not be able to get my mail.
If Commons Validator 1.1.1 rolls, and someone wants to do the same with
our 1.2.0, that would be fine with me. :)
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: When is the next release?
Posted by Ted Husted <hu...@apache.org>.
Steve Raeburn wrote:
> You can reduce the range that is checked for changes using:
> maven.changelog.range in project.properties
> It's currently set to 180 days (~6 months)
I wanted to get six-months wworth first, so I could archive enough to
get us past the 1.1 release, but I have that on-hand now, so we can set
that back to 30 days (or whatever).
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
RE: When is the next release?
Posted by Steve Raeburn <sr...@apache.org>.
You can reduce the range that is checked for changes using:
maven.changelog.range in project.properties
It's currently set to 180 days (~6 months)
Steve
> -----Original Message-----
> From: Ted Husted [mailto:husted@apache.org]
> Sent: December 2, 2003 8:57 AM
> To: Struts Developers List
> Subject: Re: When is the next release?
>
>
> Robert Leland wrote:
> > Maven already creates a changelog for struts when a
> site:generate is
> > performed.
>
> Yes, in the end, that's what I did. Had to munge it a bit to
> agree with
> our stylesheets, but no big. I checked in six month's worth,
> but didn't
> update the site since it makes for a big page. I'm thinking we can
> archive one-month blocks and link backward from the current month.
>
> My own immediate plans are to segment the changelog into one-month
> blocks, update the release notes with the appropriate
> high-level bullets
> (based on a review of the changelog), and start patching the
> documentation as needed.
>
> I believe as soon as the next Validator ships, we could go ahead and
> roll 1.2.0. It may or may not be GA material, but we should
> get it out
> there where the community can decide.
>
> -Ted.
>
>
>
> ---------------------------------------------------------------------
> 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: When is the next release?
Posted by Ted Husted <hu...@apache.org>.
Robert Leland wrote:
> Maven already creates a changelog for struts when a site:generate is
> performed.
Yes, in the end, that's what I did. Had to munge it a bit to agree with
our stylesheets, but no big. I checked in six month's worth, but didn't
update the site since it makes for a big page. I'm thinking we can
archive one-month blocks and link backward from the current month.
My own immediate plans are to segment the changelog into one-month
blocks, update the release notes with the appropriate high-level bullets
(based on a review of the changelog), and start patching the
documentation as needed.
I believe as soon as the next Validator ships, we could go ahead and
roll 1.2.0. It may or may not be GA material, but we should get it out
there where the community can decide.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: When is the next release?
Posted by Robert Leland <rl...@apache.org>.
Ted Husted wrote:
> Craig R. McClanahan wrote:
>
>> Another thing Remy does for Tomcat (which I *really* appreciate) is
>> keeps
>> a running change log (summary, not detailed) in the release notes for
>> each
>> version. That way, everyone can get a quick summary of what's changed.
>
>
> So, I'm working on one of these now for 1.1->1.2.0. I pulled the CVS
> log messages down in XML via Ant (with Don Brown's help), and I'm now
> looking at munging that into the format Tomcat is using.
Maven already creates a changelog for struts when a site:generate is
performed.
I am sure it would also work with a sub-target just for changelog.
>
> -Ted.
>
>
>
> ---------------------------------------------------------------------
> 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: When is the next release?
Posted by Ted Husted <hu...@apache.org>.
Craig R. McClanahan wrote:
> Another thing Remy does for Tomcat (which I *really* appreciate) is keeps
> a running change log (summary, not detailed) in the release notes for each
> version. That way, everyone can get a quick summary of what's changed.
So, I'm working on one of these now for 1.1->1.2.0. I pulled the CVS log
messages down in XML via Ant (with Don Brown's help), and I'm now
looking at munging that into the format Tomcat is using.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: When is the next release?
Posted by Erik Hatcher <ja...@ehatchersolutions.com>.
On Sunday, August 10, 2003, at 06:25 PM, Robert Leland wrote:
> Maven generates a change log and so does the perl script cvs2cl.pl
> (www.red-bean.com/~kfogel/cvs2cl.shtml,
And so does Ant:
http://ant.apache.org/manual/CoreTasks/changelog.html
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: When is the next release?
Posted by Robert Leland <rl...@apache.org>.
Craig R. McClanahan wrote:
>Another thing Remy does for Tomcat (which I *really* appreciate) is keeps
>a running change log (summary, not detailed) in the release notes for each
>version. That way, everyone can get a quick summary of what's changed.
>I'd like this kind of thing to be part of the release manager's
>responsibilities.
>
>
Maven generates a change log and so does the perl script cvs2cl.pl
(www.red-bean.com/~kfogel/cvs2cl.shtml,
I have been thinking about struts next release and the need to document
the ripped out methods etc.
I started to experiment with these last week. It produces a GNU style
changelog. I can help out in generating it.
-Rob
>
>
>>To ensure that two us don't start rolling a release at once, it's
>>prudent to announce your intentions first. Depending on how formal you
>>want to be, that announcement might be dubbed a "Release Plan". But the
>>only thing that matters is whether the release you roll passes a
>>Majority Vote to move it from Alpha to Beta or GA.
>>
>>At least that's how I understand it =:0)
>>
>>
>>
>
>Sounds good to me.
>
>
>
>>Since this release is not backwardly compatible with 1.1.x, having
>>removed all those deprecations, we are moving to the 1.2.x release
>>series. Until something compels us to go on to the 1.3.x series, we can
>>make be as many "General Available" releases in this series as we need.
>>
>>The current GA for Tomcat 4.1, for example, is now 4.1.27. I'm not sure,
>>but I believe the GA release before .27 was .24: .25 and .26 didn't make
>>the GA cut.
>>
>>
>
>Yep -- the ones that did were 4.1.6, 4.1.12, 4.1.18, and 4.1.24. The fact
>that it was every six is mostly coincidence and was caused by a large
>amount of refactoring work going on.
>
>
>
>>One point I'm fuzzy on is whether we should do 1.2.0 or 1.2.1 first. I
>>had thought it would be 1.2.0, but Martin and Craig seem to be saying we
>>should start with 1.2.1. Being a geek, my natural inclination was to
>>start with zero. =:0)
>>
>>
>>
>
>I'm a zero-relative guy at heart :-). My only concern is that people will
>assume 1.2.0 really means 1.2, but I'd be happy with either 1.2.0 or
>1.2.1.
>
>
>
>>-Ted.
>>
>>
>>
>
>Craig
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: struts-dev-help@jakarta.apache.org
>
>
>
>
>
--
Robert Leland Robert@free2create.org
------------------------------------------
Java, J2EE, Struts, Web Application Development
804 N. Kenmore Street +01-703-525-3580
Arlington VA 22201
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
RE: When is the next release?
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Sun, 10 Aug 2003, Steve Raeburn wrote:
> Date: Sun, 10 Aug 2003 12:51:17 -0700
> From: Steve Raeburn <sr...@apache.org>
> Reply-To: Struts Developers List <st...@jakarta.apache.org>,
> sraeburn@apache.org
> To: Struts Developers List <st...@jakarta.apache.org>
> Subject: RE: When is the next release?
>
>
>
> > -----Original Message-----
> > From: Craig R. McClanahan [mailto:craigmcc@apache.org]
> > Sent: August 10, 2003 12:37 PM
> > To: Struts Developers List
> > Subject: Re: When is the next release?
> >
> >
> > I'm a zero-relative guy at heart :-). My only concern is that people will
> > assume 1.2.0 really means 1.2, but I'd be happy with either 1.2.0 or
> > 1.2.1.
> >
>
> Craig, could you clarify what you mean by 1.2?
>
> I would assume 1.2 == 1.2.x, i.e. 1.2 represents the series of 1.2.x
> releases.
> So 1.2 would represent the 1.2 interface, but 1.2.x would be a particular
> implementation.
>
Sorry, I should have been clearer. We had a final release called "1.1",
and people who don't understand that we are changing processes might
misinterpret "1.2.0" to be "1.2 final" even though it won't be. That is
the only reason I mildly favor starting with 1.2.1, but I'd be happy with
1.2.0 as well -- we're going to have to do lots of explanations on how
things work through at least the first two or three cycles no matter what
the number is.
> Steve
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
RE: When is the next release?
Posted by Steve Raeburn <sr...@apache.org>.
> -----Original Message-----
> From: Craig R. McClanahan [mailto:craigmcc@apache.org]
> Sent: August 10, 2003 12:37 PM
> To: Struts Developers List
> Subject: Re: When is the next release?
>
>
> I'm a zero-relative guy at heart :-). My only concern is that people will
> assume 1.2.0 really means 1.2, but I'd be happy with either 1.2.0 or
> 1.2.1.
>
Craig, could you clarify what you mean by 1.2?
I would assume 1.2 == 1.2.x, i.e. 1.2 represents the series of 1.2.x
releases.
So 1.2 would represent the 1.2 interface, but 1.2.x would be a particular
implementation.
Steve
>
> 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: When is the next release?
Posted by "Craig R. McClanahan" <cr...@apache.org>.
Miscellaneous comments interspersed.
On Sun, 10 Aug 2003, Ted Husted wrote:
> Date: Sun, 10 Aug 2003 12:43:16 -0400
> From: Ted Husted <hu...@apache.org>
> Reply-To: Struts Developers List <st...@jakarta.apache.org>
> To: Struts Developers List <st...@jakarta.apache.org>
> Subject: Re: When is the next release?
>
> AFAIK, the consensus is that our releases should follow the same general
> process used by the Jakarta Commons and the Apache HTTP Server project.
>
> So, for reference, I'm following
>
> http://httpd.apache.org/dev/release.html
>
> and
>
> http://jakarta.apache.org/commons/releases/
>
> but observing the HTTPD numbering system.
>
> Right now, I intend to post a Release Plan for majority approval, either
> late tonight or early tomorrow. This Plan would include when we plan to
> roll the initial Alpha release. (I may even decided just to roll a
> release and post that along with the Plan.) We'd then vote whether to
> upgrade 1.2.1 from Alpha to Beta or General Availability (GA).
>
The way Tomcat does it, you don't even claim "alpha" status until after a
vote. They do a limited announcement of "here's the bits, try 'em out" to
just tomcat-dev and tomcat-user (essentially, it is a "test" release),
then hold the vote. I think there's merit in this approach -- stability,
like beauty, is in the eye of the beholder :-).
Also, we shouldn't be shy about just abandoning a release if it turns out
to have fatal bugs -- just fix them, and get ready for the next.
> Since there are any burning reasons to ship this instantly, I'm taking
> it as a foregone conclusion that this first roll will be at least a
> Beta. I'm confident that there are not any "serious problems that
> prohibits its use", so I don't believe it will not remain an Alpha. But,
> I do suspect that there may be "problems with this release that prohibit
> its widespread adoption" -- even if it simply documenting "what to do
> now that X is deprecated". So, I was calling it a Beta release.
>
> Once we have cleaned up the 1.2.1 roll (which I wager will only be a
> Beta), we can roll 1.2.2. Hopefully, the 1.2.2 release will merit the
> General Availability stamp. Of course, nobody knows until the vote.
>
It depends partly, of course, on what features we decide to add in each
release.
> Heretofore, we have rolled several version of the same "release" and
> then suffixed them B1, B2, and so forth. Moving forward (as I understand
> it), we of these releases get their own integer. If the release does not
> make it to GA, it dies on the vine, we and go onto the next number.
>
> In practice, you often get a odd/even pattern, where the odd was the
> "beta" or "development" version and even is the stable release. Some
> communities, like Linux, Perl, and Emacs, codify this pattern. When the
> odd-beta is sufficiently patched to make it release-worthy, they roll it
> over to the next even number and release that for general availability
>
Tomcat's 4.1 experience was that only every sixth release or so was voted
GA, at least for the first several. Now that they're up to 4.1.27, and
the number of changes is much more limited (new development is happening
in the 5.0.x series), GA things will probably happen a lot closer
together.
> AFAIK, we're not enforcing the odd/even pattern or a formal "patch
> level". So, if we roll 1.2.2 and it fails to get the votes for a GA,
> we'd go on to 1.2.3, and if that passes, it becomes the next "stable"
> release, odd or not.
>
Yep. Patterns don't really matter.
> Of course, it would even be possible for 1.2.1 to pass a GA vote, if
> someone called for one. Personally, I think that unlikely, if only for
> documentation issues. But, others could out-vote me if the consensus
> feels differently.
>
I think it's unlikely to pass a GA vote, simply because ripping out all
the deprecated stuff is a fairly major amount of surgery, and we might
have missed something. But we'll see.
> The core idea is that when any of us feel brave enough to roll a
> release, we can tag CVS with the next integer, and have at it. The
> instant we tag and roll it, it's automatically an Alpha. To upgrade the
> status from Alpha to Beta, or from Alpha to GA, we need a Majority Vote
> of the Committers (At least three committers have voted positively for a
> status and that there were more positive than negative votes (three is
> our working quorum for a binding vote)).
>
> To prevent any confusion with the CVS tags and so forth, the releases
> are immutable. Once it's rolled, it's rolled. If there's an issue that
> keeps a release from being upgraded, you either patch it, or tag and
> roll another release.
>
Absolutely. One missing detail in the plan, though, is whether we branch
on each 1.2.x release. Tomcat doesn't and I don't see a reason to since
we would probably never go back and try a 1.2.5.1 release to fix something
in 1.2.5.
Another thing Remy does for Tomcat (which I *really* appreciate) is keeps
a running change log (summary, not detailed) in the release notes for each
version. That way, everyone can get a quick summary of what's changed.
I'd like this kind of thing to be part of the release manager's
responsibilities.
> To ensure that two us don't start rolling a release at once, it's
> prudent to announce your intentions first. Depending on how formal you
> want to be, that announcement might be dubbed a "Release Plan". But the
> only thing that matters is whether the release you roll passes a
> Majority Vote to move it from Alpha to Beta or GA.
>
> At least that's how I understand it =:0)
>
Sounds good to me.
> Since this release is not backwardly compatible with 1.1.x, having
> removed all those deprecations, we are moving to the 1.2.x release
> series. Until something compels us to go on to the 1.3.x series, we can
> make be as many "General Available" releases in this series as we need.
>
> The current GA for Tomcat 4.1, for example, is now 4.1.27. I'm not sure,
> but I believe the GA release before .27 was .24: .25 and .26 didn't make
> the GA cut.
Yep -- the ones that did were 4.1.6, 4.1.12, 4.1.18, and 4.1.24. The fact
that it was every six is mostly coincidence and was caused by a large
amount of refactoring work going on.
>
> One point I'm fuzzy on is whether we should do 1.2.0 or 1.2.1 first. I
> had thought it would be 1.2.0, but Martin and Craig seem to be saying we
> should start with 1.2.1. Being a geek, my natural inclination was to
> start with zero. =:0)
>
I'm a zero-relative guy at heart :-). My only concern is that people will
assume 1.2.0 really means 1.2, but I'd be happy with either 1.2.0 or
1.2.1.
> -Ted.
>
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: When is the next release?
Posted by Vic Cekvenich <ce...@baseBeans.com>.
Any updates on 1.2.x?
Ted Husted wrote:
> AFAIK, the consensus is that our releases should follow the same general
> process used by the Jakarta Commons and the Apache HTTP Server project.
>
> So, for reference, I'm following
>
> http://httpd.apache.org/dev/release.html
>
> and
>
> http://jakarta.apache.org/commons/releases/
>
> but observing the HTTPD numbering system.
>
> Right now, I intend to post a Release Plan for majority approval, either
> late tonight or early tomorrow. This Plan would include when we plan to
> roll the initial Alpha release. (I may even decided just to roll a
> release and post that along with the Plan.) We'd then vote whether to
> upgrade 1.2.1 from Alpha to Beta or General Availability (GA).
>
> Since there are any burning reasons to ship this instantly, I'm taking
> it as a foregone conclusion that this first roll will be at least a
> Beta. I'm confident that there are not any "serious problems that
> prohibits its use", so I don't believe it will not remain an Alpha. But,
> I do suspect that there may be "problems with this release that prohibit
> its widespread adoption" -- even if it simply documenting "what to do
> now that X is deprecated". So, I was calling it a Beta release.
>
> Once we have cleaned up the 1.2.1 roll (which I wager will only be a
> Beta), we can roll 1.2.2. Hopefully, the 1.2.2 release will merit the
> General Availability stamp. Of course, nobody knows until the vote.
>
> Heretofore, we have rolled several version of the same "release" and
> then suffixed them B1, B2, and so forth. Moving forward (as I understand
> it), we of these releases get their own integer. If the release does not
> make it to GA, it dies on the vine, we and go onto the next number.
>
> In practice, you often get a odd/even pattern, where the odd was the
> "beta" or "development" version and even is the stable release. Some
> communities, like Linux, Perl, and Emacs, codify this pattern. When the
> odd-beta is sufficiently patched to make it release-worthy, they roll it
> over to the next even number and release that for general availability
>
> AFAIK, we're not enforcing the odd/even pattern or a formal "patch
> level". So, if we roll 1.2.2 and it fails to get the votes for a GA,
> we'd go on to 1.2.3, and if that passes, it becomes the next "stable"
> release, odd or not.
>
> Of course, it would even be possible for 1.2.1 to pass a GA vote, if
> someone called for one. Personally, I think that unlikely, if only for
> documentation issues. But, others could out-vote me if the consensus
> feels differently.
>
> The core idea is that when any of us feel brave enough to roll a
> release, we can tag CVS with the next integer, and have at it. The
> instant we tag and roll it, it's automatically an Alpha. To upgrade the
> status from Alpha to Beta, or from Alpha to GA, we need a Majority Vote
> of the Committers (At least three committers have voted positively for a
> status and that there were more positive than negative votes (three is
> our working quorum for a binding vote)).
>
> To prevent any confusion with the CVS tags and so forth, the releases
> are immutable. Once it's rolled, it's rolled. If there's an issue that
> keeps a release from being upgraded, you either patch it, or tag and
> roll another release.
>
> To ensure that two us don't start rolling a release at once, it's
> prudent to announce your intentions first. Depending on how formal you
> want to be, that announcement might be dubbed a "Release Plan". But the
> only thing that matters is whether the release you roll passes a
> Majority Vote to move it from Alpha to Beta or GA.
>
> At least that's how I understand it =:0)
>
> Since this release is not backwardly compatible with 1.1.x, having
> removed all those deprecations, we are moving to the 1.2.x release
> series. Until something compels us to go on to the 1.3.x series, we can
> make be as many "General Available" releases in this series as we need.
>
> The current GA for Tomcat 4.1, for example, is now 4.1.27. I'm not sure,
> but I believe the GA release before .27 was .24: .25 and .26 didn't make
> the GA cut.
>
> One point I'm fuzzy on is whether we should do 1.2.0 or 1.2.1 first. I
> had thought it would be 1.2.0, but Martin and Craig seem to be saying we
> should start with 1.2.1. Being a geek, my natural inclination was to
> start with zero. =:0)
>
> -Ted.
>
>
> Steve Raeburn wrote:
>
>>> -----Original Message-----
>>> From: Craig R. McClanahan [mailto:craigmcc@apache.org]
>>> Sent: August 9, 2003 8:57 PM
>>> To: Struts Developers List
>>> Subject: Re: When is the next release?
>>>
>>> That was my understanding as well -- we agreed to switch to the x.y.z
>>> style that Apache HTTPD and Tomcat are using, where you post the bits
>>> and
>>> then call for a vote on stability (alpha/beta/general availability).
>>> It's
>>> perfectly reasonable to have a series of "general availability" releases
>>> with new features in the 1.2.x series, as long as we continue to
>>> maintain
>>> backwards compatibility within it.
>>>
>>> Therefore the first release would be 1.2.1 and we'd keep going from
>>> there.
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
RE: When is the next release?
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Sun, 10 Aug 2003, Steve Raeburn wrote:
> Date: Sun, 10 Aug 2003 12:38:06 -0700
> From: Steve Raeburn <sr...@apache.org>
> Reply-To: Struts Developers List <st...@jakarta.apache.org>,
> sraeburn@apache.org
> To: Struts Developers List <st...@jakarta.apache.org>
> Subject: RE: When is the next release?
>
> Thanks for taking the time to explain in detail. The bit that was really
> confusing me was the idea of jumping from 1.1 to 1.2.1.
>
> I think there's got to be a 1.2.0, but I also think that it should be a
> stable, production quality release. People will infer that from the number,
> whether we like it or not.
>
There were only a very small number of people in Tomcat that didn't get
it. And now we'll have both Tomcat and Apache HTTPD to point at for how
the process works, so it shouldn't take people very long.
> >From that, it would seem that there's still a requirement for betas/rcs
> before a minor version increment.
>
Actually, the revised approach we are discussing totally *eliminates* any
predeciding what quality we think a release should be branded with. That
is discovered after the fact. The only gating factors for a new release
should be:
* Whatever changes being factored in are at a stable point
* Documentation and release notes are up to date.
If we target roughly one 1.2.x release per month, we'll be doing very
well.
> Steve
Craig
>
>
> > -----Original Message-----
> > From: Ted Husted [mailto:husted@apache.org]
> > Sent: August 10, 2003 9:43 AM
> > To: Struts Developers List
> > Subject: Re: When is the next release?
> >
> >
> > AFAIK, the consensus is that our releases should follow the same general
> > process used by the Jakarta Commons and the Apache HTTP Server project.
> >
> > So, for reference, I'm following
> >
> > http://httpd.apache.org/dev/release.html
> >
> > and
> >
> > http://jakarta.apache.org/commons/releases/
> >
> > but observing the HTTPD numbering system.
> >
> > Right now, I intend to post a Release Plan for majority approval, either
> > late tonight or early tomorrow. This Plan would include when we plan to
> > roll the initial Alpha release. (I may even decided just to roll a
> > release and post that along with the Plan.) We'd then vote whether to
> > upgrade 1.2.1 from Alpha to Beta or General Availability (GA).
> >
> > Since there are any burning reasons to ship this instantly, I'm taking
> > it as a foregone conclusion that this first roll will be at least a
> > Beta. I'm confident that there are not any "serious problems that
> > prohibits its use", so I don't believe it will not remain an Alpha. But,
> > I do suspect that there may be "problems with this release that prohibit
> > its widespread adoption" -- even if it simply documenting "what to do
> > now that X is deprecated". So, I was calling it a Beta release.
> >
> > Once we have cleaned up the 1.2.1 roll (which I wager will only be a
> > Beta), we can roll 1.2.2. Hopefully, the 1.2.2 release will merit the
> > General Availability stamp. Of course, nobody knows until the vote.
> >
> > Heretofore, we have rolled several version of the same "release" and
> > then suffixed them B1, B2, and so forth. Moving forward (as I understand
> > it), we of these releases get their own integer. If the release does not
> > make it to GA, it dies on the vine, we and go onto the next number.
> >
> > In practice, you often get a odd/even pattern, where the odd was the
> > "beta" or "development" version and even is the stable release. Some
> > communities, like Linux, Perl, and Emacs, codify this pattern. When the
> > odd-beta is sufficiently patched to make it release-worthy, they roll it
> > over to the next even number and release that for general availability
> >
> > AFAIK, we're not enforcing the odd/even pattern or a formal "patch
> > level". So, if we roll 1.2.2 and it fails to get the votes for a GA,
> > we'd go on to 1.2.3, and if that passes, it becomes the next "stable"
> > release, odd or not.
> >
> > Of course, it would even be possible for 1.2.1 to pass a GA vote, if
> > someone called for one. Personally, I think that unlikely, if only for
> > documentation issues. But, others could out-vote me if the consensus
> > feels differently.
> >
> > The core idea is that when any of us feel brave enough to roll a
> > release, we can tag CVS with the next integer, and have at it. The
> > instant we tag and roll it, it's automatically an Alpha. To upgrade the
> > status from Alpha to Beta, or from Alpha to GA, we need a Majority Vote
> > of the Committers (At least three committers have voted positively for a
> > status and that there were more positive than negative votes (three is
> > our working quorum for a binding vote)).
> >
> > To prevent any confusion with the CVS tags and so forth, the releases
> > are immutable. Once it's rolled, it's rolled. If there's an issue that
> > keeps a release from being upgraded, you either patch it, or tag and
> > roll another release.
> >
> > To ensure that two us don't start rolling a release at once, it's
> > prudent to announce your intentions first. Depending on how formal you
> > want to be, that announcement might be dubbed a "Release Plan". But the
> > only thing that matters is whether the release you roll passes a
> > Majority Vote to move it from Alpha to Beta or GA.
> >
> > At least that's how I understand it =:0)
> >
> > Since this release is not backwardly compatible with 1.1.x, having
> > removed all those deprecations, we are moving to the 1.2.x release
> > series. Until something compels us to go on to the 1.3.x series, we can
> > make be as many "General Available" releases in this series as we need.
> >
> > The current GA for Tomcat 4.1, for example, is now 4.1.27. I'm not sure,
> > but I believe the GA release before .27 was .24: .25 and .26 didn't make
> > the GA cut.
> >
> > One point I'm fuzzy on is whether we should do 1.2.0 or 1.2.1 first. I
> > had thought it would be 1.2.0, but Martin and Craig seem to be saying we
> > should start with 1.2.1. Being a geek, my natural inclination was to
> > start with zero. =:0)
> >
> > -Ted.
> >
> >
> > Steve Raeburn wrote:
> >
> > >>-----Original Message-----
> > >>From: Craig R. McClanahan [mailto:craigmcc@apache.org]
> > >>Sent: August 9, 2003 8:57 PM
> > >>To: Struts Developers List
> > >>Subject: Re: When is the next release?
> > >>
> > >>That was my understanding as well -- we agreed to switch to the x.y.z
> > >>style that Apache HTTPD and Tomcat are using, where you post
> > the bits and
> > >>then call for a vote on stability (alpha/beta/general
> > availability). It's
> > >>perfectly reasonable to have a series of "general availability" releases
> > >>with new features in the 1.2.x series, as long as we continue
> > to maintain
> > >>backwards compatibility within it.
> > >>
> > >>Therefore the first release would be 1.2.1 and we'd keep going
> > from there.
> >
> >
> >
> > ---------------------------------------------------------------------
> > 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: When is the next release?
Posted by Steve Raeburn <sr...@apache.org>.
Thanks for taking the time to explain in detail. The bit that was really
confusing me was the idea of jumping from 1.1 to 1.2.1.
I think there's got to be a 1.2.0, but I also think that it should be a
stable, production quality release. People will infer that from the number,
whether we like it or not.
>From that, it would seem that there's still a requirement for betas/rcs
before a minor version increment.
Steve
> -----Original Message-----
> From: Ted Husted [mailto:husted@apache.org]
> Sent: August 10, 2003 9:43 AM
> To: Struts Developers List
> Subject: Re: When is the next release?
>
>
> AFAIK, the consensus is that our releases should follow the same general
> process used by the Jakarta Commons and the Apache HTTP Server project.
>
> So, for reference, I'm following
>
> http://httpd.apache.org/dev/release.html
>
> and
>
> http://jakarta.apache.org/commons/releases/
>
> but observing the HTTPD numbering system.
>
> Right now, I intend to post a Release Plan for majority approval, either
> late tonight or early tomorrow. This Plan would include when we plan to
> roll the initial Alpha release. (I may even decided just to roll a
> release and post that along with the Plan.) We'd then vote whether to
> upgrade 1.2.1 from Alpha to Beta or General Availability (GA).
>
> Since there are any burning reasons to ship this instantly, I'm taking
> it as a foregone conclusion that this first roll will be at least a
> Beta. I'm confident that there are not any "serious problems that
> prohibits its use", so I don't believe it will not remain an Alpha. But,
> I do suspect that there may be "problems with this release that prohibit
> its widespread adoption" -- even if it simply documenting "what to do
> now that X is deprecated". So, I was calling it a Beta release.
>
> Once we have cleaned up the 1.2.1 roll (which I wager will only be a
> Beta), we can roll 1.2.2. Hopefully, the 1.2.2 release will merit the
> General Availability stamp. Of course, nobody knows until the vote.
>
> Heretofore, we have rolled several version of the same "release" and
> then suffixed them B1, B2, and so forth. Moving forward (as I understand
> it), we of these releases get their own integer. If the release does not
> make it to GA, it dies on the vine, we and go onto the next number.
>
> In practice, you often get a odd/even pattern, where the odd was the
> "beta" or "development" version and even is the stable release. Some
> communities, like Linux, Perl, and Emacs, codify this pattern. When the
> odd-beta is sufficiently patched to make it release-worthy, they roll it
> over to the next even number and release that for general availability
>
> AFAIK, we're not enforcing the odd/even pattern or a formal "patch
> level". So, if we roll 1.2.2 and it fails to get the votes for a GA,
> we'd go on to 1.2.3, and if that passes, it becomes the next "stable"
> release, odd or not.
>
> Of course, it would even be possible for 1.2.1 to pass a GA vote, if
> someone called for one. Personally, I think that unlikely, if only for
> documentation issues. But, others could out-vote me if the consensus
> feels differently.
>
> The core idea is that when any of us feel brave enough to roll a
> release, we can tag CVS with the next integer, and have at it. The
> instant we tag and roll it, it's automatically an Alpha. To upgrade the
> status from Alpha to Beta, or from Alpha to GA, we need a Majority Vote
> of the Committers (At least three committers have voted positively for a
> status and that there were more positive than negative votes (three is
> our working quorum for a binding vote)).
>
> To prevent any confusion with the CVS tags and so forth, the releases
> are immutable. Once it's rolled, it's rolled. If there's an issue that
> keeps a release from being upgraded, you either patch it, or tag and
> roll another release.
>
> To ensure that two us don't start rolling a release at once, it's
> prudent to announce your intentions first. Depending on how formal you
> want to be, that announcement might be dubbed a "Release Plan". But the
> only thing that matters is whether the release you roll passes a
> Majority Vote to move it from Alpha to Beta or GA.
>
> At least that's how I understand it =:0)
>
> Since this release is not backwardly compatible with 1.1.x, having
> removed all those deprecations, we are moving to the 1.2.x release
> series. Until something compels us to go on to the 1.3.x series, we can
> make be as many "General Available" releases in this series as we need.
>
> The current GA for Tomcat 4.1, for example, is now 4.1.27. I'm not sure,
> but I believe the GA release before .27 was .24: .25 and .26 didn't make
> the GA cut.
>
> One point I'm fuzzy on is whether we should do 1.2.0 or 1.2.1 first. I
> had thought it would be 1.2.0, but Martin and Craig seem to be saying we
> should start with 1.2.1. Being a geek, my natural inclination was to
> start with zero. =:0)
>
> -Ted.
>
>
> Steve Raeburn wrote:
>
> >>-----Original Message-----
> >>From: Craig R. McClanahan [mailto:craigmcc@apache.org]
> >>Sent: August 9, 2003 8:57 PM
> >>To: Struts Developers List
> >>Subject: Re: When is the next release?
> >>
> >>That was my understanding as well -- we agreed to switch to the x.y.z
> >>style that Apache HTTPD and Tomcat are using, where you post
> the bits and
> >>then call for a vote on stability (alpha/beta/general
> availability). It's
> >>perfectly reasonable to have a series of "general availability" releases
> >>with new features in the 1.2.x series, as long as we continue
> to maintain
> >>backwards compatibility within it.
> >>
> >>Therefore the first release would be 1.2.1 and we'd keep going
> from there.
>
>
>
> ---------------------------------------------------------------------
> 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: When is the next release?
Posted by Robert Leland <rl...@apache.org>.
David Graham wrote:
>--- Ted Husted <hu...@apache.org> wrote:
>
>
>>AFAIK, the consensus is that our releases should follow the same general
>>
>>process used by the Jakarta Commons and the Apache HTTP Server project.
>>
>>So, for reference, I'm following
>>
>>http://httpd.apache.org/dev/release.html
>>
>>and
>>
>>http://jakarta.apache.org/commons/releases/
>>
>>but observing the HTTPD numbering system.
>>
>>Right now, I intend to post a Release Plan for majority approval, either
>>
>>late tonight or early tomorrow. This Plan would include when we plan to
>>roll the initial Alpha release. (I may even decided just to roll a
>>release and post that along with the Plan.) We'd then vote whether to
>>upgrade 1.2.1 from Alpha to Beta or General Availability (GA).
>>
>>Since there are any burning reasons to ship this instantly, I'm taking
>>it as a foregone conclusion that this first roll will be at least a
>>Beta. I'm confident that there are not any "serious problems that
>>prohibits its use", so I don't believe it will not remain an Alpha. But,
>>
>>I do suspect that there may be "problems with this release that prohibit
>>
>>its widespread adoption" -- even if it simply documenting "what to do
>>now that X is deprecated". So, I was calling it a Beta release.
>>
>>
>
>We already documented this in the 1.1 @deprecated tags. I don't think we
>need more documentation on the deprecations.
>
>David
>
We need to document the every removed method and class, at least in the
release notes. Once the deprecated
methods/classes are taken out there is not a bread crumb trail to follow
and it will cost use more work answering
questions on the users list than if we document it to start with. That
way when they don't read the release notes
we can cut and paste the URL to the release notes.
Robert Leland Robert@free2create.org
------------------------------------------
Java, J2EE, Struts, Web Application Development
804 N. Kenmore Street +01-703-525-3580
Arlington VA 22201
Re: When is the next release?
Posted by Ted Husted <hu...@apache.org>.
David Graham wrote:
> We already documented this in the 1.1 @deprecated tags. I don't think we
> need more documentation on the deprecations.
Then maybe the best thing is to post the Alpha and ask people to tender
their vote as to whether it should remain an Alpha, go to Beta, or go to
General Release.
---- SAMPLE ONLY, NO VOTES PLEASE ----
( ) +1 for ( )Alpha, ( )Beta, ( )General Release (select one status)
( ) -1 for Beta or General Release status
----
Also, as I understand it, these votes are revocable, so if a problem
surfaced, we could also downgrade the status of a release and declare
another to be the "best available version".
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: When is the next release?
Posted by David Graham <gr...@yahoo.com>.
--- Ted Husted <hu...@apache.org> wrote:
> AFAIK, the consensus is that our releases should follow the same general
>
> process used by the Jakarta Commons and the Apache HTTP Server project.
>
> So, for reference, I'm following
>
> http://httpd.apache.org/dev/release.html
>
> and
>
> http://jakarta.apache.org/commons/releases/
>
> but observing the HTTPD numbering system.
>
> Right now, I intend to post a Release Plan for majority approval, either
>
> late tonight or early tomorrow. This Plan would include when we plan to
> roll the initial Alpha release. (I may even decided just to roll a
> release and post that along with the Plan.) We'd then vote whether to
> upgrade 1.2.1 from Alpha to Beta or General Availability (GA).
>
> Since there are any burning reasons to ship this instantly, I'm taking
> it as a foregone conclusion that this first roll will be at least a
> Beta. I'm confident that there are not any "serious problems that
> prohibits its use", so I don't believe it will not remain an Alpha. But,
>
> I do suspect that there may be "problems with this release that prohibit
>
> its widespread adoption" -- even if it simply documenting "what to do
> now that X is deprecated". So, I was calling it a Beta release.
We already documented this in the 1.1 @deprecated tags. I don't think we
need more documentation on the deprecations.
David
>
> Once we have cleaned up the 1.2.1 roll (which I wager will only be a
> Beta), we can roll 1.2.2. Hopefully, the 1.2.2 release will merit the
> General Availability stamp. Of course, nobody knows until the vote.
>
> Heretofore, we have rolled several version of the same "release" and
> then suffixed them B1, B2, and so forth. Moving forward (as I understand
>
> it), we of these releases get their own integer. If the release does not
>
> make it to GA, it dies on the vine, we and go onto the next number.
>
> In practice, you often get a odd/even pattern, where the odd was the
> "beta" or "development" version and even is the stable release. Some
> communities, like Linux, Perl, and Emacs, codify this pattern. When the
> odd-beta is sufficiently patched to make it release-worthy, they roll it
>
> over to the next even number and release that for general availability
>
> AFAIK, we're not enforcing the odd/even pattern or a formal "patch
> level". So, if we roll 1.2.2 and it fails to get the votes for a GA,
> we'd go on to 1.2.3, and if that passes, it becomes the next "stable"
> release, odd or not.
>
> Of course, it would even be possible for 1.2.1 to pass a GA vote, if
> someone called for one. Personally, I think that unlikely, if only for
> documentation issues. But, others could out-vote me if the consensus
> feels differently.
>
> The core idea is that when any of us feel brave enough to roll a
> release, we can tag CVS with the next integer, and have at it. The
> instant we tag and roll it, it's automatically an Alpha. To upgrade the
> status from Alpha to Beta, or from Alpha to GA, we need a Majority Vote
> of the Committers (At least three committers have voted positively for a
>
> status and that there were more positive than negative votes (three is
> our working quorum for a binding vote)).
>
> To prevent any confusion with the CVS tags and so forth, the releases
> are immutable. Once it's rolled, it's rolled. If there's an issue that
> keeps a release from being upgraded, you either patch it, or tag and
> roll another release.
>
> To ensure that two us don't start rolling a release at once, it's
> prudent to announce your intentions first. Depending on how formal you
> want to be, that announcement might be dubbed a "Release Plan". But the
> only thing that matters is whether the release you roll passes a
> Majority Vote to move it from Alpha to Beta or GA.
>
> At least that's how I understand it =:0)
>
> Since this release is not backwardly compatible with 1.1.x, having
> removed all those deprecations, we are moving to the 1.2.x release
> series. Until something compels us to go on to the 1.3.x series, we can
> make be as many "General Available" releases in this series as we need.
>
> The current GA for Tomcat 4.1, for example, is now 4.1.27. I'm not sure,
>
> but I believe the GA release before .27 was .24: .25 and .26 didn't make
>
> the GA cut.
>
> One point I'm fuzzy on is whether we should do 1.2.0 or 1.2.1 first. I
> had thought it would be 1.2.0, but Martin and Craig seem to be saying we
>
> should start with 1.2.1. Being a geek, my natural inclination was to
> start with zero. =:0)
>
> -Ted.
>
>
> Steve Raeburn wrote:
>
> >>-----Original Message-----
> >>From: Craig R. McClanahan [mailto:craigmcc@apache.org]
> >>Sent: August 9, 2003 8:57 PM
> >>To: Struts Developers List
> >>Subject: Re: When is the next release?
> >>
> >>That was my understanding as well -- we agreed to switch to the x.y.z
> >>style that Apache HTTPD and Tomcat are using, where you post the bits
> and
> >>then call for a vote on stability (alpha/beta/general availability).
> It's
> >>perfectly reasonable to have a series of "general availability"
> releases
> >>with new features in the 1.2.x series, as long as we continue to
> maintain
> >>backwards compatibility within it.
> >>
> >>Therefore the first release would be 1.2.1 and we'd keep going from
> there.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-dev-help@jakarta.apache.org
>
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: When is the next release?
Posted by Ted Husted <hu...@apache.org>.
AFAIK, the consensus is that our releases should follow the same general
process used by the Jakarta Commons and the Apache HTTP Server project.
So, for reference, I'm following
http://httpd.apache.org/dev/release.html
and
http://jakarta.apache.org/commons/releases/
but observing the HTTPD numbering system.
Right now, I intend to post a Release Plan for majority approval, either
late tonight or early tomorrow. This Plan would include when we plan to
roll the initial Alpha release. (I may even decided just to roll a
release and post that along with the Plan.) We'd then vote whether to
upgrade 1.2.1 from Alpha to Beta or General Availability (GA).
Since there are any burning reasons to ship this instantly, I'm taking
it as a foregone conclusion that this first roll will be at least a
Beta. I'm confident that there are not any "serious problems that
prohibits its use", so I don't believe it will not remain an Alpha. But,
I do suspect that there may be "problems with this release that prohibit
its widespread adoption" -- even if it simply documenting "what to do
now that X is deprecated". So, I was calling it a Beta release.
Once we have cleaned up the 1.2.1 roll (which I wager will only be a
Beta), we can roll 1.2.2. Hopefully, the 1.2.2 release will merit the
General Availability stamp. Of course, nobody knows until the vote.
Heretofore, we have rolled several version of the same "release" and
then suffixed them B1, B2, and so forth. Moving forward (as I understand
it), we of these releases get their own integer. If the release does not
make it to GA, it dies on the vine, we and go onto the next number.
In practice, you often get a odd/even pattern, where the odd was the
"beta" or "development" version and even is the stable release. Some
communities, like Linux, Perl, and Emacs, codify this pattern. When the
odd-beta is sufficiently patched to make it release-worthy, they roll it
over to the next even number and release that for general availability
AFAIK, we're not enforcing the odd/even pattern or a formal "patch
level". So, if we roll 1.2.2 and it fails to get the votes for a GA,
we'd go on to 1.2.3, and if that passes, it becomes the next "stable"
release, odd or not.
Of course, it would even be possible for 1.2.1 to pass a GA vote, if
someone called for one. Personally, I think that unlikely, if only for
documentation issues. But, others could out-vote me if the consensus
feels differently.
The core idea is that when any of us feel brave enough to roll a
release, we can tag CVS with the next integer, and have at it. The
instant we tag and roll it, it's automatically an Alpha. To upgrade the
status from Alpha to Beta, or from Alpha to GA, we need a Majority Vote
of the Committers (At least three committers have voted positively for a
status and that there were more positive than negative votes (three is
our working quorum for a binding vote)).
To prevent any confusion with the CVS tags and so forth, the releases
are immutable. Once it's rolled, it's rolled. If there's an issue that
keeps a release from being upgraded, you either patch it, or tag and
roll another release.
To ensure that two us don't start rolling a release at once, it's
prudent to announce your intentions first. Depending on how formal you
want to be, that announcement might be dubbed a "Release Plan". But the
only thing that matters is whether the release you roll passes a
Majority Vote to move it from Alpha to Beta or GA.
At least that's how I understand it =:0)
Since this release is not backwardly compatible with 1.1.x, having
removed all those deprecations, we are moving to the 1.2.x release
series. Until something compels us to go on to the 1.3.x series, we can
make be as many "General Available" releases in this series as we need.
The current GA for Tomcat 4.1, for example, is now 4.1.27. I'm not sure,
but I believe the GA release before .27 was .24: .25 and .26 didn't make
the GA cut.
One point I'm fuzzy on is whether we should do 1.2.0 or 1.2.1 first. I
had thought it would be 1.2.0, but Martin and Craig seem to be saying we
should start with 1.2.1. Being a geek, my natural inclination was to
start with zero. =:0)
-Ted.
Steve Raeburn wrote:
>>-----Original Message-----
>>From: Craig R. McClanahan [mailto:craigmcc@apache.org]
>>Sent: August 9, 2003 8:57 PM
>>To: Struts Developers List
>>Subject: Re: When is the next release?
>>
>>That was my understanding as well -- we agreed to switch to the x.y.z
>>style that Apache HTTPD and Tomcat are using, where you post the bits and
>>then call for a vote on stability (alpha/beta/general availability). It's
>>perfectly reasonable to have a series of "general availability" releases
>>with new features in the 1.2.x series, as long as we continue to maintain
>>backwards compatibility within it.
>>
>>Therefore the first release would be 1.2.1 and we'd keep going from there.
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
RE: When is the next release?
Posted by Steve Raeburn <sr...@apache.org>.
> -----Original Message-----
> From: Craig R. McClanahan [mailto:craigmcc@apache.org]
> Sent: August 9, 2003 8:57 PM
> To: Struts Developers List
> Subject: Re: When is the next release?
>
> That was my understanding as well -- we agreed to switch to the x.y.z
> style that Apache HTTPD and Tomcat are using, where you post the bits and
> then call for a vote on stability (alpha/beta/general availability). It's
> perfectly reasonable to have a series of "general availability" releases
> with new features in the 1.2.x series, as long as we continue to maintain
> backwards compatibility within it.
>
> Therefore the first release would be 1.2.1 and we'd keep going from there.
I think it would be strange to go directly to a 1.2.1 release, which I
suspect is why Ted was talking about a beta.
Tomcat has a 4_1_0 tag in CVS, but I don't know if that was released as
such.
It's not my intention to reopen an old discussion, but I would like to
confirm exactly what version this will be.
Steve
>
>
> Craig
>
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: When is the next release?
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Sat, 9 Aug 2003, Robert Leland wrote:
> Date: Sat, 09 Aug 2003 22:42:43 -0400
> From: Robert Leland <rl...@apache.org>
> Reply-To: Struts Developers List <st...@jakarta.apache.org>
> To: Struts Developers List <st...@jakarta.apache.org>
> Subject: Re: When is the next release?
>
> Ted Husted wrote:
>
> > Just a head's up. I'd like to draw up a Release Plan tomorrow for
> > Struts 1.2 beta 1. I'd like to get this out so people can start
> > migrating to the "non-deprecated Struts 1.1+" (for lack of a better
> > term) *before* we get into the Commons Resources thing.
> >
> > Since we did so much backward-compatiblity work on Struts 1.1, getting
> > the deprecations out of some of the older code will be no small task
> > for some people, but the sooner we get the community started on this,
> > the better.
> >
> > If anyone else would like to be the Release Manager, please feel free
> > to chime in. I'd be happy to pass the baton once the plan is in place.
>
>
> Are we going to take the struts-legacy out this build or remove it for 1.3.
> If so then the data source code will need to be removed, before the beta.
> Beta implies a stable interface.
> Also I thought we were going to do away with alpha/beta/RC .... anyway.
>
That was my understanding as well -- we agreed to switch to the x.y.z
style that Apache HTTPD and Tomcat are using, where you post the bits and
then call for a vote on stability (alpha/beta/general availability). It's
perfectly reasonable to have a series of "general availability" releases
with new features in the 1.2.x series, as long as we continue to maintain
backwards compatibility within it.
Therefore the first release would be 1.2.1 and we'd keep going from there.
> >
> >
> > -Ted.
> >
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
RE: When is the next release?
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Sat, 9 Aug 2003, Steve Raeburn wrote:
> Date: Sat, 9 Aug 2003 20:10:16 -0700
> From: Steve Raeburn <sr...@apache.org>
> Reply-To: Struts Developers List <st...@jakarta.apache.org>,
> sraeburn@apache.org
> To: Struts Developers List <st...@jakarta.apache.org>
> Subject: RE: When is the next release?
>
> > -----Original Message-----
> > From: Robert Leland [mailto:rleland@apache.org]
> > Sent: August 9, 2003 7:43 PM
> > To: Struts Developers List
> > Subject: Re: When is the next release?
> >
> >
> > Are we going to take the struts-legacy out this build or remove
> > it for 1.3.
>
> I'm for removing it. I can do this if no one else is on it already.
>
> I'd also like to remove the <html:form> deprecated attributes (name, style,
> type) if there are no objections.
>
If we have remaining 1.1 deprecations, I'd prefer we cleaned them all out
before the first 1.2 release so nobody assumes that we'll have to keep
them all the way through a 1.2.x lifetime.
> > If so then the data source code will need to be removed, before the beta.
> > Beta implies a stable interface.
> > Also I thought we were going to do away with alpha/beta/RC .... anyway.
>
> I'm sure I read a message on that a couple of days ago, but I can't find it
> now. (Must be losing it)
> Anyway, the gist was that we don't have a current non-stable/development
> release (odd numbered) so we'd need a Beta.
>
> If I could find the message I might understand it myself :-)
>
See my previous response re: the way that Tomcat and Apache HTTPD do it.
That's what we agreed to use for 1.2, quite a while back.
> Steve
Craig
>
> >
> > >
> > >
> > > -Ted.
> > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: struts-dev-help@jakarta.apache.org
> > >
> > >
> > >
> >
> >
> > --
> > Robert Leland Robert@free2create.org
> > ------------------------------------------
> > Java, J2EE, Struts, Web Application Development
> >
> > 804 N. Kenmore Street +01-703-525-3580
> > Arlington VA 22201
> >
> >
> >
> > ---------------------------------------------------------------------
> > 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: When is the next release?
Posted by Steve Raeburn <sr...@apache.org>.
I hope I wasn't being presumptive. You can always put it back if you want to
remove it :-)
Steve
> -----Original Message-----
> From: Ted Husted [mailto:husted@apache.org]
> Sent: August 10, 2003 9:17 AM
> To: Struts Developers List
> Subject: Re: When is the next release?
>
>
> Steve Raeburn wrote:
> > I'm for removing it. I can do this if no one else is on it already.
>
> David said he thought I was going to do it, and I thought David was
> going to do it, so let's split the difference and let Steve do it =:)
>
> -Ted.
>
>
>
> ---------------------------------------------------------------------
> 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: When is the next release?
Posted by Ted Husted <hu...@apache.org>.
Steve Raeburn wrote:
> I'm for removing it. I can do this if no one else is on it already.
David said he thought I was going to do it, and I thought David was
going to do it, so let's split the difference and let Steve do it =:)
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
RE: When is the next release?
Posted by Steve Raeburn <sr...@apache.org>.
> -----Original Message-----
> From: Robert Leland [mailto:rleland@apache.org]
> Sent: August 9, 2003 7:43 PM
> To: Struts Developers List
> Subject: Re: When is the next release?
>
>
> Are we going to take the struts-legacy out this build or remove
> it for 1.3.
I'm for removing it. I can do this if no one else is on it already.
I'd also like to remove the <html:form> deprecated attributes (name, style,
type) if there are no objections.
> If so then the data source code will need to be removed, before the beta.
> Beta implies a stable interface.
> Also I thought we were going to do away with alpha/beta/RC .... anyway.
I'm sure I read a message on that a couple of days ago, but I can't find it
now. (Must be losing it)
Anyway, the gist was that we don't have a current non-stable/development
release (odd numbered) so we'd need a Beta.
If I could find the message I might understand it myself :-)
Steve
>
> >
> >
> > -Ted.
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: struts-dev-help@jakarta.apache.org
> >
> >
> >
>
>
> --
> Robert Leland Robert@free2create.org
> ------------------------------------------
> Java, J2EE, Struts, Web Application Development
>
> 804 N. Kenmore Street +01-703-525-3580
> Arlington VA 22201
>
>
>
> ---------------------------------------------------------------------
> 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: When is the next release?
Posted by Robert Leland <rl...@apache.org>.
Ted Husted wrote:
> Just a head's up. I'd like to draw up a Release Plan tomorrow for
> Struts 1.2 beta 1. I'd like to get this out so people can start
> migrating to the "non-deprecated Struts 1.1+" (for lack of a better
> term) *before* we get into the Commons Resources thing.
>
> Since we did so much backward-compatiblity work on Struts 1.1, getting
> the deprecations out of some of the older code will be no small task
> for some people, but the sooner we get the community started on this,
> the better.
>
> If anyone else would like to be the Release Manager, please feel free
> to chime in. I'd be happy to pass the baton once the plan is in place.
Are we going to take the struts-legacy out this build or remove it for 1.3.
If so then the data source code will need to be removed, before the beta.
Beta implies a stable interface.
Also I thought we were going to do away with alpha/beta/RC .... anyway.
>
>
> -Ted.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-dev-help@jakarta.apache.org
>
>
>
--
Robert Leland Robert@free2create.org
------------------------------------------
Java, J2EE, Struts, Web Application Development
804 N. Kenmore Street +01-703-525-3580
Arlington VA 22201
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: When is the next release?
Posted by David Graham <gr...@yahoo.com>.
--- Ted Husted <hu...@apache.org> wrote:
> Just a head's up. I'd like to draw up a Release Plan tomorrow for Struts
>
> 1.2 beta 1. I'd like to get this out so people can start migrating to
> the "non-deprecated Struts 1.1+" (for lack of a better term) *before* we
>
> get into the Commons Resources thing.
I think this is a great time to release 1.2. Aside from getting the
massive amount of deprecated code out of Struts, we're also releasing bug
fixes and quite a few minor enhancements. It will also be nice to get out
of the dreaded 1.1 series :-). Thanks for handling the release Ted!
David
>
> Since we did so much backward-compatiblity work on Struts 1.1, getting
> the deprecations out of some of the older code will be no small task for
>
> some people, but the sooner we get the community started on this, the
> better.
>
> If anyone else would like to be the Release Manager, please feel free to
>
> chime in. I'd be happy to pass the baton once the plan is in place.
>
> -Ted.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-dev-help@jakarta.apache.org
>
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: When is the next release?
Posted by Ted Husted <hu...@apache.org>.
Just a head's up. I'd like to draw up a Release Plan tomorrow for Struts
1.2 beta 1. I'd like to get this out so people can start migrating to
the "non-deprecated Struts 1.1+" (for lack of a better term) *before* we
get into the Commons Resources thing.
Since we did so much backward-compatiblity work on Struts 1.1, getting
the deprecations out of some of the older code will be no small task for
some people, but the sooner we get the community started on this, the
better.
If anyone else would like to be the Release Manager, please feel free to
chime in. I'd be happy to pass the baton once the plan is in place.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: When is the next release?
Posted by David Graham <gr...@yahoo.com>.
> > >
> >
> > Many of these are nested and Tiles related and I don't think those
> should
> > block a release.
>
> I disagree. Tiles and Nested are first class citizens, and currently
> part of
> the Struts core. There is absolutely no reason to claim that bugs in
> these
> components are less important than bugs in any other part of the core.
> Perhaps you don't use them, but many others do, and they should not be
> slighted.
I think you misunderstood. I do use Tiles in my apps and it works fine
for me. Many of these open bugs were marked LATER for 1.1 and I believe
they should be marked LATER for 1.2. Let's be honest. Tiles and Nested
have one person working on them respectively (their authors). We should
not hold up releases for "bugs" in those components.
>
> I've said it before, and I'll say it again - more frequent releases does
> *not* mean lower quality releases. You can be sure I'll back that up.
>
> >
> > > I'll take a look at these to see if there's anything that would
> block a
> > > release. If not, I could roll a release on Sunday and try to do it
> > > HTTPD-style, so that we can do it without a freeze.
> >
> > Would this be a 1.2 RC1 or final?
>
> I think it has to be Beta 1. I know we're supposed to be using this new
> Tomcat-style numbering scheme, but my understanding is that even numbers
> mean stable releases. That being the case, there has to be some
> stabilising
> mechanism before we can get to the first release, because 0 is an even
> number. (In other words, a 1.2.1 release would be the stabilising
> release
> before a stable 1.2.2, but how do you stabilise before a 1.2.0 release?)
>
> >
> > >
> > > http://httpd.apache.org/dev/release.html
> > >
> > > I'll cut the candidate and post it for review and a vote. If it
> passes,
> > > it passes; if not, we re-tag and try again.
> > >
> > > I do think it would be a good idea to get a post 1.1 release out now
> so
> > > people will start updating their code to not use the 1.1
> deprecations.
> >
> > +1
>
> -0. Personally, I don't think that, by itself, is a good enough
> criterion
> for a release, but I don't feel strongly enough about that to block it
> if
> other people disagree.
It's not the main reason to release 1.2. There have been many
enhancements and bug fixes since 1.1 and now seems like a decent time to
release 1.2.
David
>
> >
> > >
> > > After 1.2.0, we could start with the 1.2.x releases, until we do
> > > something drastic like drop in a Composable RequestProcessor or move
> a
> > > dependence to another JAR (e.g. Commons Resources).
> >
> > I've always thought that point releases are bugfixes only with no
> > enhancements. Also, point releases don't allow us to remove
> deprecated
> > features. How would these change under a 1.2.x type of release
> scheme?
>
> Point releases (e.g. going from 1.2.0 to 1.2.2) are indeed bug fixes
> only
> and no new features. New features require a minor version increment
> (e.g.
> 1.2.0 to 1.3.0). When we do "something drastic" (to use Ted's words ;),
> we'll need to go to a1.3.x lineage. That will quite likely mean creating
> branches, if we want to work on both bug fix releases and new features
> simultaneously in the CVS tree.
>
> --
> Martin Cooper
>
>
> >
> > David
> >
> > >
> > > -Ted.
> > >
> > > David Graham wrote:
> > > > I think we could release 1.2 now if there was a release manager.
> I
> > > don't
> > > > have the time to learn and perform the release process right now.
> > > >
> > > > David
> > > >
> > > > --- Nick Lesincki <nl...@yahoo.com> wrote:
> > > >
> > > >>It has been at least 1 month since question was asked
> > > >>When is the next release?
> > > >>Last msg said 1 month after 1.1 and a release manager
> > > >>was required and some bug fixes would be out.
> > > >>
> > > >>Nicolas
> > >
> > >
> > >
> > >
> ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: struts-dev-help@jakarta.apache.org
> > >
> >
> >
> > __________________________________
> > Do you Yahoo!?
> > Yahoo! SiteBuilder - Free, easy-to-use web site design software
> > http://sitebuilder.yahoo.com
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-dev-help@jakarta.apache.org
>
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: When is the next release?
Posted by Martin Cooper <ma...@apache.org>.
"David Graham" <gr...@yahoo.com> wrote in message
news:20030807140109.11784.qmail@web20711.mail.yahoo.com...
> --- Ted Husted <hu...@apache.org> wrote:
> > There are 18 non-enhancement tickets in Bugzilla.
> >
> >
>
http://issues.apache.org/bugzilla/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=VERIFIED&bug_severity=Blocker&bug_severity=Critical&bug_severity=Major&bug_severity=Normal&bug_severity=Minor&email1=&emailtype1=substring&emailassigned_to1=1&email2=&emailtype2=substring&emailreporter2=1&bugidtype=include&bug_id=&changedin=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&product=Struts&short_desc=&short_desc_type=allwordssubstr&long_desc=&long_desc_type=allwordssubstr&bug_file_loc=&bug_file_loc_type=allwordssubstr&keywords=&keywords_type=anywords&field0-0-0=noop&type0-0-0=noop&value0-0-0=&cmdtype=doit&order=Bug+Number
> >
>
> Many of these are nested and Tiles related and I don't think those should
> block a release.
I disagree. Tiles and Nested are first class citizens, and currently part of
the Struts core. There is absolutely no reason to claim that bugs in these
components are less important than bugs in any other part of the core.
Perhaps you don't use them, but many others do, and they should not be
slighted.
I've said it before, and I'll say it again - more frequent releases does
*not* mean lower quality releases. You can be sure I'll back that up.
>
> > I'll take a look at these to see if there's anything that would block a
> > release. If not, I could roll a release on Sunday and try to do it
> > HTTPD-style, so that we can do it without a freeze.
>
> Would this be a 1.2 RC1 or final?
I think it has to be Beta 1. I know we're supposed to be using this new
Tomcat-style numbering scheme, but my understanding is that even numbers
mean stable releases. That being the case, there has to be some stabilising
mechanism before we can get to the first release, because 0 is an even
number. (In other words, a 1.2.1 release would be the stabilising release
before a stable 1.2.2, but how do you stabilise before a 1.2.0 release?)
>
> >
> > http://httpd.apache.org/dev/release.html
> >
> > I'll cut the candidate and post it for review and a vote. If it passes,
> > it passes; if not, we re-tag and try again.
> >
> > I do think it would be a good idea to get a post 1.1 release out now so
> > people will start updating their code to not use the 1.1 deprecations.
>
> +1
-0. Personally, I don't think that, by itself, is a good enough criterion
for a release, but I don't feel strongly enough about that to block it if
other people disagree.
>
> >
> > After 1.2.0, we could start with the 1.2.x releases, until we do
> > something drastic like drop in a Composable RequestProcessor or move a
> > dependence to another JAR (e.g. Commons Resources).
>
> I've always thought that point releases are bugfixes only with no
> enhancements. Also, point releases don't allow us to remove deprecated
> features. How would these change under a 1.2.x type of release scheme?
Point releases (e.g. going from 1.2.0 to 1.2.2) are indeed bug fixes only
and no new features. New features require a minor version increment (e.g.
1.2.0 to 1.3.0). When we do "something drastic" (to use Ted's words ;),
we'll need to go to a1.3.x lineage. That will quite likely mean creating
branches, if we want to work on both bug fix releases and new features
simultaneously in the CVS tree.
--
Martin Cooper
>
> David
>
> >
> > -Ted.
> >
> > David Graham wrote:
> > > I think we could release 1.2 now if there was a release manager. I
> > don't
> > > have the time to learn and perform the release process right now.
> > >
> > > David
> > >
> > > --- Nick Lesincki <nl...@yahoo.com> wrote:
> > >
> > >>It has been at least 1 month since question was asked
> > >>When is the next release?
> > >>Last msg said 1 month after 1.1 and a release manager
> > >>was required and some bug fixes would be out.
> > >>
> > >>Nicolas
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: struts-dev-help@jakarta.apache.org
> >
>
>
> __________________________________
> Do you Yahoo!?
> Yahoo! SiteBuilder - Free, easy-to-use web site design software
> http://sitebuilder.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: When is the next release?
Posted by David Graham <gr...@yahoo.com>.
--- Ted Husted <hu...@apache.org> wrote:
> There are 18 non-enhancement tickets in Bugzilla.
>
>
http://issues.apache.org/bugzilla/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=VERIFIED&bug_severity=Blocker&bug_severity=Critical&bug_severity=Major&bug_severity=Normal&bug_severity=Minor&email1=&emailtype1=substring&emailassigned_to1=1&email2=&emailtype2=substring&emailreporter2=1&bugidtype=include&bug_id=&changedin=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&product=Struts&short_desc=&short_desc_type=allwordssubstr&long_desc=&long_desc_type=allwordssubstr&bug_file_loc=&bug_file_loc_type=allwordssubstr&keywords=&keywords_type=anywords&field0-0-0=noop&type0-0-0=noop&value0-0-0=&cmdtype=doit&order=Bug+Number
>
Many of these are nested and Tiles related and I don't think those should
block a release.
> I'll take a look at these to see if there's anything that would block a
> release. If not, I could roll a release on Sunday and try to do it
> HTTPD-style, so that we can do it without a freeze.
Would this be a 1.2 RC1 or final?
>
> http://httpd.apache.org/dev/release.html
>
> I'll cut the candidate and post it for review and a vote. If it passes,
> it passes; if not, we re-tag and try again.
>
> I do think it would be a good idea to get a post 1.1 release out now so
> people will start updating their code to not use the 1.1 deprecations.
+1
>
> After 1.2.0, we could start with the 1.2.x releases, until we do
> something drastic like drop in a Composable RequestProcessor or move a
> dependence to another JAR (e.g. Commons Resources).
I've always thought that point releases are bugfixes only with no
enhancements. Also, point releases don't allow us to remove deprecated
features. How would these change under a 1.2.x type of release scheme?
David
>
> -Ted.
>
> David Graham wrote:
> > I think we could release 1.2 now if there was a release manager. I
> don't
> > have the time to learn and perform the release process right now.
> >
> > David
> >
> > --- Nick Lesincki <nl...@yahoo.com> wrote:
> >
> >>It has been at least 1 month since question was asked
> >>When is the next release?
> >>Last msg said 1 month after 1.1 and a release manager
> >>was required and some bug fixes would be out.
> >>
> >>Nicolas
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-dev-help@jakarta.apache.org
>
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: When is the next release?
Posted by Ted Husted <hu...@apache.org>.
There are 18 non-enhancement tickets in Bugzilla.
http://issues.apache.org/bugzilla/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=VERIFIED&bug_severity=Blocker&bug_severity=Critical&bug_severity=Major&bug_severity=Normal&bug_severity=Minor&email1=&emailtype1=substring&emailassigned_to1=1&email2=&emailtype2=substring&emailreporter2=1&bugidtype=include&bug_id=&changedin=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&product=Struts&short_desc=&short_desc_type=allwordssubstr&long_desc=&long_desc_type=allwordssubstr&bug_file_loc=&bug_file_loc_type=allwordssubstr&keywords=&keywords_type=anywords&field0-0-0=noop&type0-0-0=noop&value0-0-0=&cmdtype=doit&order=Bug+Number
I'll take a look at these to see if there's anything that would block a
release. If not, I could roll a release on Sunday and try to do it
HTTPD-style, so that we can do it without a freeze.
http://httpd.apache.org/dev/release.html
I'll cut the candidate and post it for review and a vote. If it passes,
it passes; if not, we re-tag and try again.
I do think it would be a good idea to get a post 1.1 release out now so
people will start updating their code to not use the 1.1 deprecations.
After 1.2.0, we could start with the 1.2.x releases, until we do
something drastic like drop in a Composable RequestProcessor or move a
dependence to another JAR (e.g. Commons Resources).
-Ted.
David Graham wrote:
> I think we could release 1.2 now if there was a release manager. I don't
> have the time to learn and perform the release process right now.
>
> David
>
> --- Nick Lesincki <nl...@yahoo.com> wrote:
>
>>It has been at least 1 month since question was asked
>>When is the next release?
>>Last msg said 1 month after 1.1 and a release manager
>>was required and some bug fixes would be out.
>>
>>Nicolas
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
RE: When is the next release?
Posted by David Graham <gr...@yahoo.com>.
I think we could release 1.2 now if there was a release manager. I don't
have the time to learn and perform the release process right now.
David
--- Nick Lesincki <nl...@yahoo.com> wrote:
> It has been at least 1 month since question was asked
> When is the next release?
> Last msg said 1 month after 1.1 and a release manager
> was required and some bug fixes would be out.
>
> Nicolas
>
>
> __________________________________
> Do you Yahoo!?
> Yahoo! SiteBuilder - Free, easy-to-use web site design software
> http://sitebuilder.yahoo.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-dev-help@jakarta.apache.org
>
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org