I'm thinking for 1.2 we can start by moving whatever we want to work on from LATER to active again, doing the deed, and marked them resolved again.
I would not be in favor of anything that even smells like a "requirements list".
As soon as we have something worth releasing, we should start the release cycle. Personally, post 1.1, I'd like to consider monthly betas, and then promoting a beta to a release candidate whenever one seems solid enough.
If we had been doing that last year, we could have gotten some very handy taglib changes into production a year ago Christmas, before we got started on the module/validator/tiles cycles. (And each of those should also have been a release unto itself.)
We simply don't have the resources to pick a feature set in advance. We need to go with what we got as soon as we got it. Anything less is a disservice to our community.
We also need to start decoupling the components of the current distribution. Again, we don't have the resources to coordinate everything with everything else. We need to be able to change something, confirm that it works with the legacy production code, and get it out there where people can use it.
If, for example, Tiles is unstable become of some new work, we can't let that hold up a release of Struts EL, or whatever else. There will be questions of which release of what works with what, but that's a just a documentation issue. As it stands, we have to face the fact that we have serious production issues, which, like security, trumps.
-Ted.
David Graham wrote:
Ted,
I agree with you but want to add the item Craig and I discussed earlier regarding the standard actions throwing exceptions instead of sending error codes to the user.
We need a small requirements list for 1.2 and ship it when we've completed those items. I don't want to relive the lengthy 1.1 cycle and the *many* new features (and bugs) introduced.
David
From: Ted Husted <[EMAIL PROTECTED]>
Reply-To: "Struts Developers List" <[EMAIL PROTECTED]>
To: Struts Developers List <[EMAIL PROTECTED]>
Subject: Re: exit strategy was Plans for the upcoming 2/14 soft deadline
Date: Tue, 04 Feb 2003 13:34:34 -0500
I made a pass on Bugzilla, and we seem to be down to three tickets.
http://jakarta.apache.org/struts/proposals/release-plan-1.1b3.html
Two seem module related and the third relates to the nested taglib. All three indicate incorrect behavior. I'd call these three our remaining showstoppers, unless another committer says otherwise.
For 1.2, I'd like to concentrate on applying the patches we already have waiting in the LATER bin, do the Commons Resource migration, fix any early 1.1 bug reports, and call it a release. Anything the least bit new or controversial could be tagged for 1.3/2.x. Gotta get the momentum up =:0)
-T.
Vic Cekvenich wrote:
If I can say ....
Please consider releasing nightly build (w/o EL) very, very soon, as a RC1;
+ plus a note of the know bugs.
(I know it's not ideal, but it's an *exit* strategy).
As soon as the bugs are fixed, release.
Of course if something *new* shows up in RC1, then have RC2.
At this point I would rather have 1.1a if something new shows up; other
Jakarta projects have.
Note: I plant to try to take basicPortal.com to Jakarta incubator, very
soon, coments welcome.
And if anyone wants to contribute to an online class (people only pay
"WebEx" charges), coming up very soon.
vc at basebeans.com
Then my 1.2 wishlist (Craig?)
- HTML-el
- ship with JSTL (Maven?)
- deprecate templates
- deprecate (means will be gone after 2.0) beans tag (so people can use core
tag)
- split struts jar in 2. One for tags(and nested), one for rest. (So one day
Struts could move most it's tags to jakarta.taglibs. Thus people can render
anyway they want, ex: Faces tag)
- include simple version of Scafolding BaseAction (w/ default disptach) and
BaseFormBean (w/ beantuils to copy multirow) - This hints people in a good
direction.
- better tiles and login example (Container based security)
- filters? listeners?
- please include struts-menu by S. Skyles (in strutstags.jar), it is popular
as any tag and singe point for navigations.
- faces "extension"
- multi row example app in contrib ?
- master/detail example app in contrib ?
- Servlet 2.3
(be glad to do half of any of above)
Past 2.0 wish list:
- Axis controller
- Commons-SQL or Castor (or RowSet) example app w/Struts.
- DAO interface/factory (in Commons?)
- Deprecate most tags (let people use taglibs for render,or Velocity, or
faces....) but support JSP 2.0 in this release (HTML-EL, Faces, Tiles,
Validator only; no logic, etc. support)
- XML "generator". Have you used JasperReports? "He" create an XML file that
"compiles" to something else. So if we create a XML file (with bands?) that
"compiles" to JSP and struts.config, ,etc.? Then others can write XML
generators for any output. Of course, base extension classes behind.
- JDK1.4 required
- Servlet 2.4
- There were a lot of 2.0 ideas.... I can't recall them.
It is more exciting past 1.1.
.V
"Ted Husted" <[EMAIL PROTECTED]> wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
I would agree with Craig that dates are good motivators for cuttinghttp://archives.apache.org/eyebrowse/ReadMsg?[EMAIL PROTECTED]
betas, but to cut a Release Candidate, logically, we need to be
release-ready. The objective release-ready test is what shows up in
Bugzilla. So, someone has to either fix or defer (in good conscious) any
outstanding tickets.
As for the Release Plan, we can continue to amend the B3 page. When
we're ready for R1, make the final revisions and re-post it under a new
name. Since everything should be done by then, the freeze date can be
set for +(72 hours), to coincide with the close of the vote.
At this point, I just don't have any more blood to shed for 1.1. If we
can't get this thing out the door in February, then we should look for
some more comitters who can.
Either way, come March, I say it's time to get a fresh,
test-first-design start on 2.x. A year of FUD is more than enough.
-Ted.
Martin Cooper wrote:
Ted had suggested that we resolve the outstanding items first, and then
put together a release plan, complete with tag date. See:
che.org&msgId=612913
However, I don't believe that's working. In fact, as I believe Tedhimselfsaid of the 1.1-b3 drive, having a date to aim for is a bettermotivator.Unfortunately, as I mentioned before, I don't have much time to helpkilloutstanding bug reports for RC1, due to current "day job" pressures.It'dbe great to see an RC1 on or around Feb 14th, and I can do the RM thing,
but I'm going to have to rely on others of you to get us ready for that.
Also, what is the status of the idea of separating the contrib libraries
out of the release? I'm not certain what the result was of any vote on
this, but I had the impression there wasn't enough response to make a
decision.
IMO, Struts-EL should stay put until we get Struts 1.1 out the door.Afterthat, we can discuss how to incorporate contrib code into the release as
part of a broader discussion of how to factor distributions.
--
Martin Cooper
-- Ted Husted, Struts in Action <http://husted.com/struts/book.html>--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]-- Ted Husted, Struts in Action <http://husted.com/struts/book.html> --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
_________________________________________________________________
The new MSN 8: advanced junk mail protection and 2 months FREE* http://join.msn.com/?page=features/junkmail
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-- Ted Husted, Struts in Action <http://husted.com/struts/book.html> --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
