Hopefully, there will be a final release of FileUpload early in June, so we can pop that in and go to final.
The underlying problem has nothing to do with the Apache process. We simply tried to release too many things at once. If we had done step-wise releases (tag improvements/ nested/ modules/ validator/ tiles/ jstl/ etc), we wouldn't be in this jam. By rights, we should be at something like Struts 1.8 by now.
As soon as Struts 1.1 is out the door, I'd like to remove the deprecations and release Struts 1.2. It's gotten so that it's hard to see the forest for the trees anymore.
We should then try to relase whenever a useful feature is added, so as to put it in the hands of people as soon as possible.
-Ted.
James Turner wrote:
From: Martin Cooper [mailto:[EMAIL PROTECTED]
First off, big thanks to Martin for adopting FileUpload and getting this puppy back in shape.
Now, about the Struts 1.1 RC2 release. The problem is the staging needed to get FileUpload out the door. It's currently at Beta 1, and the code base in CVS has some methods that have been deprecated since Beta 1. The deprecated methods need to be removed before 1.0 Final, which means that we need a Beta 2 to publicise the deprecations. Then they can be removed in an RC1, shortly to be followed (hopefully) by 1.0 Final.
Much as I would like to see Struts 1.1 RC2 happen before JavaOne, I just don't see how that can happen, given the steps that FileUpload has to go through before a final release.
Does this strike anyone but me as an example of the victory of process over sanity?
Why does a deprecation/removal of some methods require a new beta? If your code depends on the deprecated methods, you can stick with whatever you're using now until you can fix your code, and then use the release. If you don't, you can evaluate the RC, and an entire step can be saved.
The entire Struts 1.1 release has been a Kafka-esq adventure in strict adherence to a set of rules that, IMHO, has done nothing but add months of delay to an already terminally late release. It's hard to believe there's something that makes the JCP look speedy, but consider that in the time we've been struggling to get 1.1 out the door, JSF has gone almost completely from proposal to EA.
Open source is supposed to be speedy and responsive, instead we're starting to make Microsoft look like a speed demon. The Apache rules serve a good purpose, to prevent shoddy releases. But at this point, we've got a major release hanging fire on (frankly) some relatively obscure supporting packages which aren't even used by the majority of the user community.
If I were benevolent dictator for a day, I'd do a 1.1 RC2 now with the FileUpload Beta 2. But, since we live in an enlightened society, I'm putting it up for a vote.
As we've been reminded recently, this type of voice is non-veto-able, lazy majority
SO:
+1 - Yes, release Struts RC2 with FileUpload 1.1 Beta 2 once Martin releases it.
0 - Eh
-1 - I prefer to delay Struts RC2 until FileUpload is in final release.
The 72 hour voting cutoff is 3AM Eastern June 1
James
--------------------------------------------------------------------- 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]
