Re: VOTE (enough already!): Release Struts RC2 with FileUpload Beta 2
Struts is a product of the Apache Software Foundation... [cut] ...we can learn from our mistakes and cut a release whenever we add a feature that people can put to good use (instead of after we have added a large set of new features). -Ted. Couldn't agree more (hence my +1), new RC for JavaOne will be great. Just saying, things seem to have shifted a little. Arron. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: VOTE (enough already!): Release Struts RC2 with FileUpload Beta 2
The other issue here, and one I'm sure that a lot of other folks on the list who interact with the public a lot can sympathize with, is that there are a LOT of commercial entities still using 1.0 because they have a policy of not using beta software. I cringe when I think of all the people suffering needlessly under the yoke of 1.0's limitations, and thus have been increasingly frustrated at the delays in getting 1.1 out. Oh yah, and I wanna get my new validations into the repository too (truth in advertising...) James - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: VOTE (enough already!): Release Struts RC2 with FileUpload Beta 2
+1 I agree that deprecating methods does not require a new beta. We don't guarantee backwards compatibility between betas. James, can you act as release manager for RC2? Sounds like Martin won't have time to do it. David 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] _ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: VOTE (enough already!): Release Struts RC2 with FileUpload Beta 2
+1 -- James Mitchell Software Developer/Struts Evangelist http://www.struts-atlanta.org - Original Message - From: David Graham [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, May 29, 2003 9:47 AM Subject: Re: VOTE (enough already!): Release Struts RC2 with FileUpload Beta 2 +1 I agree that deprecating methods does not require a new beta. We don't guarantee backwards compatibility between betas. James, can you act as release manager for RC2? Sounds like Martin won't have time to do it. David 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] _ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: VOTE (enough already!): Release Struts RC2 with FileUpload Beta 2
From: David Graham [mailto:[EMAIL PROTECTED] +1 I agree that deprecating methods does not require a new beta. We don't guarantee backwards compatibility between betas. James, can you act as release manager for RC2? Sounds like Martin won't have time to do it. David I'd be happy to, if A) someone will grant me karma on the Jakarta web site and B) someone can walk me through the basic steps involved, as I've deferred to Martin Release Addict Cooper on these matters in previous releases I've managed. James - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: VOTE (enough already!): Release Struts RC2 with FileUpload Beta 2
+1. Let's do it! -James - Original Message - From: James Turner [EMAIL PROTECTED] To: 'Struts Developers List' [EMAIL PROTECTED] Sent: Thursday, May 29, 2003 3:05 AM Subject: VOTE (enough already!): Release Struts RC2 with FileUpload Beta 2 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: VOTE (enough already!): Release Struts RC2 with FileUpload Beta 2
I'd be happy to, if A) someone will grant me karma on the Jakarta web site and B) someone can walk me through the basic steps involved, as I've deferred to Martin Release Addict Cooper on these matters in previous releases I've managed. I believe all Jakarta committers have karma on the website. The commons has this release guide: http://jakarta.apache.org/commons/releases.html Did anyone from Struts document our specific steps? David James _ STOP MORE SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: VOTE (enough already!): Release Struts RC2 with FileUpload Beta 2
Well, I just tried logging into jakarta.apache.org, and I don't have login privs, so I guess I don't have karma. James -Original Message- From: David Graham [mailto:[EMAIL PROTECTED] Sent: Thursday, May 29, 2003 1:41 PM To: [EMAIL PROTECTED] Subject: RE: VOTE (enough already!): Release Struts RC2 with FileUpload Beta 2 I'd be happy to, if A) someone will grant me karma on the Jakarta web site and B) someone can walk me through the basic steps involved, as I've deferred to Martin Release Addict Cooper on these matters in previous releases I've managed. I believe all Jakarta committers have karma on the website. The commons has this release guide: http://jakarta.apache.org/commons/releases.html Did anyone from Struts document our specific steps? David James _ STOP MORE SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: VOTE (enough already!): Release Struts RC2 with FileUpload Beta 2
Is that a +1 for the vote? James -Original Message- From: Ted Husted [mailto:[EMAIL PROTECTED] Sent: Thursday, May 29, 2003 7:19 PM To: Struts Developers List Subject: Re: VOTE (enough already!): Release Struts RC2 with FileUpload Beta 2 I have enough karma to make the release, if Martin is busy, and that's what everyone wants to do. I've put the pieces in place to remove the DBCP dependency, but need to actually release that as well. 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: VOTE (enough already!): Release Struts RC2 with FileUpload Beta 2
+1 This puppy's more than stable enough to cut another RC. I understand why Martin wants the FileUpload to go through the wringer, and it should, but it's already the most spiffy-est upload component there is. Beta2 of FileUpload has my vote for RC2. Somehow in all this I get the nagging feeling that Struts now has an agenda which it's never had before. It was just cutting quality software, hang the time it took. Regarding James' Open source is supposed to be speedy and responsive, where did you get this idea from?... only open source projects that are truly speedy drop the quality aspect in order to obtain it, unless I'm missing something obvious?... Take Exolab's Castor and how slow that's moving. But what a fine product, and not even at 1.0. Arron. +1 I agree that deprecating methods does not require a new beta. We don't guarantee backwards compatibility between betas. James, can you act as release manager for RC2? Sounds like Martin won't have time to do it. David 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] _ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: VOTE (enough already!): Release Struts RC2 with FileUpload Beta 2
I aint no committer/contributor but if I get 2 cents worth (about 1.15 US cents) its: +1 Do it! Do it now! -Original Message- From: James Turner [mailto:[EMAIL PROTECTED] Sent: Thursday, 29 May 2003 15:06 To: 'Struts Developers List' Subject: VOTE (enough already!): Release Struts RC2 with FileUpload Beta 2 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: VOTE (enough already!): Release Struts RC2 with FileUpload Beta 2
+1 from a non-committer (but sometimes contributor) as well. Release it! Then if someone complains of a bug, it'll get fixed and another release can come out. On Thursday, May 29, 2003, at 03:15 AM, Andrew Hill wrote: I aint no committer/contributor but if I get 2 cents worth (about 1.15 US cents) its: +1 Do it! Do it now! -Original Message- From: James Turner [mailto:[EMAIL PROTECTED] Sent: Thursday, 29 May 2003 15:06 To: 'Struts Developers List' Subject: VOTE (enough already!): Release Struts RC2 with FileUpload Beta 2 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RE: VOTE (enough already!): Release Struts RC2 with FileUpload Beta 2
+1 here ! On Thu, 29 May 2003 Andrew Hill wrote : I aint no committer/contributor but if I get 2 cents worth (about 1.15 US cents) its: +1 Do it! Do it now! -Original Message- From: James Turner [mailto:[EMAIL PROTECTED] Sent: Thursday, 29 May 2003 15:06 To: 'Struts Developers List' Subject: VOTE (enough already!): Release Struts RC2 with FileUpload Beta 2 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] ___ Get email that means BUSINESS! me @ mycompany.com. Just Rs.1499/year. To start, click http://www.rediffmailpro.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
