On Wed, 20 Feb 2002, Ted Husted wrote:
> Date: Wed, 20 Feb 2002 07:52:03 -0500
> From: Ted Husted <[EMAIL PROTECTED]>
> Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> To: Struts Developers List <[EMAIL PROTECTED]>
> Subject: Re: [PROPOSAL] Modular Applications (the BIG checkin) [LONG]
>
> I agree that a beta based on the current nightly build is a reasonable
> course of action for now.
>
There's one more thing on my "gotta have it" list -- integrating the setup
of services from struts-config.xml (although I'm not 100% happy with the
current commons-services APIs, I will converse about that on commons-dev).
This will remove the most common reason that people have to subclass
ActionServlet, and will thus insulate them from internal changes to that
implementation.
> My real regret is that we did not get a chance to cut a 1.1 release
> before the last wave of improvements came done the pipeline. My concern
> is that either the release-cycle will now be extended, while we absorb
> the new features, or will be rushed, just to move things along.
>
> Of course, Craig's work is consistently excellent, and the likelihood of
> any actual problems is slight to none.
>
So far, so good ... :-)
> My underlying goal is to remind us that Struts is being used by some
> very serious teams on some very serious projects. These teams rely on
> the "#.#" release stamp to tell them that the codebase is ready for
> primetime, and it is our responsibility to ensure that it is.
>
> I would usually expect changes this significant to live in the nightly
> build for several months before release. But, keeping the other features
> out the hands of production teams is now bordering on cruelty.
>
I'm thinking we want to clearly differentiate between a "beta" (features
could still change, we could even yank the BIG check-in if it causes more
compatibility problems than we currently anticipate) and a "release
candidate" (critical bugfixes only). I hope we go through at least a
couple of release candidates before final release.
> So, I guess, it comes down to "in for a penny, in for a pound"; are we
> ready to cut a beta?
>
Subject to adding services (I will be able to work on it this weekend),
+1.
> -Ted.
>
Craig
>
>
> "Deadman, Hal" wrote:
> >
> > I assume there will be at least one beta release of Struts 1.1 and a release
> > candidate after that. That will provide ample time to identify any specific
> > incompatibilities and address them. At least we will be able to identify the
> > exact cause of the incompatibility and then we can discuss a specific
> > problem rather than unidentified issues.
> >
> > It's too early to give up on the ideal solution which is not adding a second
> > package. A second package will cause grief similar to the struts-form.tld.
> > The periodic bug reports of people trying to use that taglib are annoying
> > but imagine the time the bug reporters wasted trying to use that taglib. It
> > probably would have saved the world some time if it had been removed prior
> > to 1.0. People using pre-1.0 Struts or pre-1.1 nightly builds should expect
> > to make some minor changes if they upgrade. Especially when the changes will
> > save them time in the long run.
> >
> > People moving from 1.0 to 1.1 are already in for some global search and
> > replace due to the commons stuff. They are also going to have to do some
> > extensive testing because a great deal of changes have been made, aside from
> > the Big check-in.
> >
> > Nobody needs to upgrade an application that is well underway with a
> > particular version of Struts. If they do upgrade then they need to examine
> > the migration issues and weigh the migration cost against benefits of the
> > new features. Hopefully there won't be any known migration issues that
> > aren't resolved during a beta release.
> >
> > Hal
>
> --
> To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
>
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
