Re: [VOTE] 1.2.0 Release Plan
--- Paul Sundling [EMAIL PROTECTED] wrote: One possible question is from the new boilerplate: Copyright [] [name of copyright owner] Is it just The Apache Software Foundation, like in the 1.1 license? That would be my guess. I think that's correct. The documentation uses that string in the examples. David The one reference to Struts in the previous license version was related to the section on use of the trademark name. I think that's dealt with in a more general way in the new license. Paul Sundling David Graham wrote: The exact license details can be found here: http://www.apache.org/dev/apply-license.html David --- Karr, David [EMAIL PROTECTED] wrote: Does this involve changing the file header comment to replace the existing license with the new license? That's something that I can relatively easily script in elisp macros. If someone can confirm that's all this is, and show me exactly what needs to change, I can get that done this weekend. -Original Message- From: Joe Germuska [mailto:[EMAIL PROTECTED] Sent: Friday, February 20, 2004 12:12 PM To: Struts Developers List Subject: Re: [VOTE] 1.2.0 Release Plan 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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Mail SpamGuard - Read only the mail you want. http://antispam.yahoo.com/tools - 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] __ Do you Yahoo!? Yahoo! Mail SpamGuard - Read only the mail you want. http://antispam.yahoo.com/tools - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] 1.2.0 Release Plan
David Karr emailed me, so I'll take care of the licenses this weekend. I have a social engagement today, so I'll take care of it on sunday. Paul Sundling David Graham wrote: --- Paul Sundling [EMAIL PROTECTED] wrote: One possible question is from the new boilerplate: Copyright [] [name of copyright owner] Is it just The Apache Software Foundation, like in the 1.1 license? That would be my guess. I think that's correct. The documentation uses that string in the examples. David The one reference to Struts in the previous license version was related to the section on use of the trademark name. I think that's dealt with in a more general way in the new license. Paul Sundling David Graham wrote: The exact license details can be found here: http://www.apache.org/dev/apply-license.html David --- Karr, David [EMAIL PROTECTED] wrote: Does this involve changing the file header comment to replace the existing license with the new license? That's something that I can relatively easily script in elisp macros. If someone can confirm that's all this is, and show me exactly what needs to change, I can get that done this weekend. -Original Message- From: Joe Germuska [mailto:[EMAIL PROTECTED] Sent: Friday, February 20, 2004 12:12 PM To: Struts Developers List Subject: Re: [VOTE] 1.2.0 Release Plan 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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Mail SpamGuard - Read only the mail you want. http://antispam.yahoo.com/tools - 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] __ Do you Yahoo!? Yahoo! Mail SpamGuard - Read only the mail you want. http://antispam.yahoo.com/tools - 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] 1.2.0 Release Plan
Thanks for volunteering! I will review and apply the patch once it's entered in bugzilla. David --- Paul Sundling [EMAIL PROTECTED] wrote: David Karr emailed me, so I'll take care of the licenses this weekend. I have a social engagement today, so I'll take care of it on sunday. Paul Sundling David Graham wrote: --- Paul Sundling [EMAIL PROTECTED] wrote: One possible question is from the new boilerplate: Copyright [] [name of copyright owner] Is it just The Apache Software Foundation, like in the 1.1 license? That would be my guess. I think that's correct. The documentation uses that string in the examples. David The one reference to Struts in the previous license version was related to the section on use of the trademark name. I think that's dealt with in a more general way in the new license. Paul Sundling David Graham wrote: The exact license details can be found here: http://www.apache.org/dev/apply-license.html David --- Karr, David [EMAIL PROTECTED] wrote: Does this involve changing the file header comment to replace the existing license with the new license? That's something that I can relatively easily script in elisp macros. If someone can confirm that's all this is, and show me exactly what needs to change, I can get that done this weekend. -Original Message- From: Joe Germuska [mailto:[EMAIL PROTECTED] Sent: Friday, February 20, 2004 12:12 PM To: Struts Developers List Subject: Re: [VOTE] 1.2.0 Release Plan 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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Mail SpamGuard - Read only the mail you want. http://antispam.yahoo.com/tools - 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] __ Do you Yahoo!? Yahoo! Mail SpamGuard - Read only the mail you want. http://antispam.yahoo.com/tools - 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] __ Do you Yahoo!? Yahoo! Mail SpamGuard - Read only the mail you want. http://antispam.yahoo.com/tools - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] 1.2.0 Release Plan
-Original Message- From: Karr, David [mailto:[EMAIL PROTECTED] Sent: Saturday, February 21, 2004 12:46 AM To: 'Struts Developers List' Subject: RE: [VOTE] 1.2.0 Release Plan Does this involve changing the file header comment to replace the existing license with the new license? That's something that I can relatively easily script in elisp macros. If someone can confirm that's all this is, and show me exactly what needs to change, I can get that done this weekend. The committers project in CVS has python java versions that does this automatically. The Python version has undergone several versions to improve the copyright conversion. You might want to start there first. -ROb - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [VOTE] 1.2.0 Release Plan
-Original Message- From: Paul Sundling [mailto:[EMAIL PROTECTED] Sent: Saturday, February 21, 2004 7:52 AM To: Struts Developers List Subject: Re: [VOTE] 1.2.0 Release Plan David Karr emailed me, so I'll take care of the licenses this weekend. I have a social engagement today, so I'll take care of it on sunday. Thanks for doing this, Paul. One caveat: The tag/freeze for 1.2.0 happens tonight at midnight my time. Since there are often a few tweaks that happen after the tag and before the release itself, you might want to hold off until the release is uploaded (or I send a Houston, we have lift-off message) before updating your source tree. (It turns out that I have a social engagement today also, so I can't take care of this before tag/freeze either.) -- Martin Cooper Paul Sundling David Graham wrote: --- Paul Sundling [EMAIL PROTECTED] wrote: One possible question is from the new boilerplate: Copyright [] [name of copyright owner] Is it just The Apache Software Foundation, like in the 1.1 license? That would be my guess. I think that's correct. The documentation uses that string in the examples. David The one reference to Struts in the previous license version was related to the section on use of the trademark name. I think that's dealt with in a more general way in the new license. Paul Sundling David Graham wrote: The exact license details can be found here: http://www.apache.org/dev/apply-license.html David --- Karr, David [EMAIL PROTECTED] wrote: Does this involve changing the file header comment to replace the existing license with the new license? That's something that I can relatively easily script in elisp macros. If someone can confirm that's all this is, and show me exactly what needs to change, I can get that done this weekend. -Original Message- From: Joe Germuska [mailto:[EMAIL PROTECTED] Sent: Friday, February 20, 2004 12:12 PM To: Struts Developers List Subject: Re: [VOTE] 1.2.0 Release Plan 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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Mail SpamGuard - Read only the mail you want. http://antispam.yahoo.com/tools - 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] __ Do you Yahoo!? Yahoo! Mail SpamGuard - Read only the mail you want. http://antispam.yahoo.com/tools - 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: [VOTE] 1.2.0 Release Plan
-Original Message- From: Joe Germuska [mailto:[EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [VOTE] 1.2.0 Release Plan
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Saturday, February 21, 2004 8:10 AM To: Struts Developers List Subject: Re: [VOTE] 1.2.0 Release Plan -Original Message- From: Karr, David [mailto:[EMAIL PROTECTED] Sent: Saturday, February 21, 2004 12:46 AM To: 'Struts Developers List' Subject: RE: [VOTE] 1.2.0 Release Plan Does this involve changing the file header comment to replace the existing license with the new license? That's something that I can relatively easily script in elisp macros. If someone can confirm that's all this is, and show me exactly what needs to change, I can get that done this weekend. The committers project in CVS has python java versions that does this automatically. The Python version has undergone several versions to improve the copyright conversion. You might want to start there first. Yes, I would also suggest going with the Python version. It's seen considerably more usage, across Apache, than the Java one has at this point, so is more likely to have had the wrinkles ironed out. -- Martin Cooper -ROb - 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] 1.2.0 Release Plan
I woke up earlier than planned (I'm on a strange sleep schedule) and Robert Leland got me a copy of the tools, which saved me a bunch of time since my own tool was only 40% done. I used the java one, since python is the one LAMP language I don't know. I fixed one of the problems in the java tool README and another not mentioned. I still have to test the CheckStyle maven reports and read and/or parse through the 38K line patch file to make sure everything is OK. I estimate I'll finish about 5:30pm PST today, so unless the midnight my time is england or something I should finish well before the cutoff, leaving some a couple hours for a committer to check it out. Paul Sundling Martin Cooper wrote: -Original Message- From: Paul Sundling [mailto:[EMAIL PROTECTED] Sent: Saturday, February 21, 2004 7:52 AM To: Struts Developers List Subject: Re: [VOTE] 1.2.0 Release Plan David Karr emailed me, so I'll take care of the licenses this weekend. I have a social engagement today, so I'll take care of it on sunday. Thanks for doing this, Paul. One caveat: The tag/freeze for 1.2.0 happens tonight at midnight my time. Since there are often a few tweaks that happen after the tag and before the release itself, you might want to hold off until the release is uploaded (or I send a Houston, we have lift-off message) before updating your source tree. (It turns out that I have a social engagement today also, so I can't take care of this before tag/freeze either.) -- Martin Cooper Paul Sundling David Graham wrote: --- Paul Sundling [EMAIL PROTECTED] wrote: One possible question is from the new boilerplate: Copyright [] [name of copyright owner] Is it just The Apache Software Foundation, like in the 1.1 license? That would be my guess. I think that's correct. The documentation uses that string in the examples. David The one reference to Struts in the previous license version was related to the section on use of the trademark name. I think that's dealt with in a more general way in the new license. Paul Sundling David Graham wrote: The exact license details can be found here: http://www.apache.org/dev/apply-license.html David --- Karr, David [EMAIL PROTECTED] wrote: Does this involve changing the file header comment to replace the existing license with the new license? That's something that I can relatively easily script in elisp macros. If someone can confirm that's all this is, and show me exactly what needs to change, I can get that done this weekend. -Original Message- From: Joe Germuska [mailto:[EMAIL PROTECTED] Sent: Friday, February 20, 2004 12:12 PM To: Struts Developers List Subject: Re: [VOTE] 1.2.0 Release Plan 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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Mail SpamGuard - Read only the mail you want. http://antispam.yahoo.com/tools - 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] __ Do you Yahoo!? Yahoo! Mail SpamGuard - Read only the mail you want. http://antispam.yahoo.com/tools - 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] 1.2.0 Release Plan
Be sure to put the CVS TAGS in the refernce license.txt so it will add them automatically, at least the python version was ok with that. -Rob -Original Message- From: Paul Sundling [mailto:[EMAIL PROTECTED] Sent: Saturday, February 21, 2004 11:27 PM To: 'Struts Developers List' Subject: Re: [VOTE] 1.2.0 Release Plan I woke up earlier than planned (I'm on a strange sleep schedule) and Robert Leland got me a copy of the tools, which saved me a bunch of time since my own tool was only 40% done. I used the java one, since python is the one LAMP language I don't know. I fixed one of the problems in the java tool README and another not mentioned. I still have to test the CheckStyle maven reports and read and/or parse through the 38K line patch file to make sure everything is OK. I estimate I'll finish about 5:30pm PST today, so unless the midnight my time is england or something I should finish well before the cutoff, leaving some a couple hours for a committer to check it out. Paul Sundling Martin Cooper wrote: -Original Message- From: Paul Sundling [mailto:[EMAIL PROTECTED] Sent: Saturday, February 21, 2004 7:52 AM To: Struts Developers List Subject: Re: [VOTE] 1.2.0 Release Plan David Karr emailed me, so I'll take care of the licenses this weekend. I have a social engagement today, so I'll take care of it on sunday. Thanks for doing this, Paul. One caveat: The tag/freeze for 1.2.0 happens tonight at midnight my time. Since there are often a few tweaks that happen after the tag and before the release itself, you might want to hold off until the release is uploaded (or I send a Houston, we have lift-off message) before updating your source tree. (It turns out that I have a social engagement today also, so I can't take care of this before tag/freeze either.) -- Martin Cooper Paul Sundling David Graham wrote: --- Paul Sundling [EMAIL PROTECTED] wrote: One possible question is from the new boilerplate: Copyright [] [name of copyright owner] Is it just The Apache Software Foundation, like in the 1.1 license? That would be my guess. I think that's correct. The documentation uses that string in the examples. David The one reference to Struts in the previous license version was related to the section on use of the trademark name. I think that's dealt with in a more general way in the new license. Paul Sundling David Graham wrote: The exact license details can be found here: http://www.apache.org/dev/apply-license.html David --- Karr, David [EMAIL PROTECTED] wrote: Does this involve changing the file header comment to replace the existing license with the new license? That's something that I can relatively easily script in elisp macros. If someone can confirm that's all this is, and show me exactly what needs to change, I can get that done this weekend. -Original Message- From: Joe Germuska [mailto:[EMAIL PROTECTED] Sent: Friday, February 20, 2004 12:12 PM To: Struts Developers List Subject: Re: [VOTE] 1.2.0 Release Plan 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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Mail SpamGuard - Read only the mail you want. http://antispam.yahoo.com/tools - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail
Re: [VOTE] 1.2.0 Release Plan
David Graham, I finished 3 minutes ahead of my estimated time. :) Unfortunately, it's taking forever (30 minutes so far) to upload the patch file, which is just shy of 2 megs. Would it speed things up any to send you a copy directly, while it's uploading? I thought I'd ask since we're on a tight deadline. Paul Sundling David Graham wrote: Thanks for volunteering! I will review and apply the patch once it's entered in bugzilla. David - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] 1.2.0 Release Plan
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] 1.2.0 Release Plan
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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] 1.2.0 Release Plan
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] 1.2.0 Release Plan
--- Martin Cooper [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Mail SpamGuard - Read only the mail you want. http://antispam.yahoo.com/tools - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] 1.2.0 Release Plan
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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. (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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] 1.2.0 Release Plan
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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [VOTE] 1.2.0 Release Plan
Does this involve changing the file header comment to replace the existing license with the new license? That's something that I can relatively easily script in elisp macros. If someone can confirm that's all this is, and show me exactly what needs to change, I can get that done this weekend. -Original Message- From: Joe Germuska [mailto:[EMAIL PROTECTED] Sent: Friday, February 20, 2004 12:12 PM To: Struts Developers List Subject: Re: [VOTE] 1.2.0 Release Plan 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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] 1.2.0 Release Plan
Besides changing header, there's also maintaining copyrights and moving them to a new location and then updating a Checkstyle version of the license. I did the last major license update and I'd be willing to do it as well this weekend. Just let me know. Paul Sundling Karr, David wrote: Does this involve changing the file header comment to replace the existing license with the new license? That's something that I can relatively easily script in elisp macros. If someone can confirm that's all this is, and show me exactly what needs to change, I can get that done this weekend. -Original Message- From: Joe Germuska [mailto:[EMAIL PROTECTED] Sent: Friday, February 20, 2004 12:12 PM To: Struts Developers List Subject: Re: [VOTE] 1.2.0 Release Plan 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [VOTE] 1.2.0 Release Plan
The exact license details can be found here: http://www.apache.org/dev/apply-license.html David --- Karr, David [EMAIL PROTECTED] wrote: Does this involve changing the file header comment to replace the existing license with the new license? That's something that I can relatively easily script in elisp macros. If someone can confirm that's all this is, and show me exactly what needs to change, I can get that done this weekend. -Original Message- From: Joe Germuska [mailto:[EMAIL PROTECTED] Sent: Friday, February 20, 2004 12:12 PM To: Struts Developers List Subject: Re: [VOTE] 1.2.0 Release Plan 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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Mail SpamGuard - Read only the mail you want. http://antispam.yahoo.com/tools - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] 1.2.0 Release Plan
One possible question is from the new boilerplate: Copyright [] [name of copyright owner] Is it just The Apache Software Foundation, like in the 1.1 license? That would be my guess. The one reference to Struts in the previous license version was related to the section on use of the trademark name. I think that's dealt with in a more general way in the new license. Paul Sundling David Graham wrote: The exact license details can be found here: http://www.apache.org/dev/apply-license.html David --- Karr, David [EMAIL PROTECTED] wrote: Does this involve changing the file header comment to replace the existing license with the new license? That's something that I can relatively easily script in elisp macros. If someone can confirm that's all this is, and show me exactly what needs to change, I can get that done this weekend. -Original Message- From: Joe Germuska [mailto:[EMAIL PROTECTED] Sent: Friday, February 20, 2004 12:12 PM To: Struts Developers List Subject: Re: [VOTE] 1.2.0 Release Plan 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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Mail SpamGuard - Read only the mail you want. http://antispam.yahoo.com/tools - 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] 1.2.0 Release Plan
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] 1.2.0 Release Plan
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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] 1.2.0 Release Plan
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] 1.2.0 Release Plan
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] 1.2.0 Release Plan
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] 1.2.0 Release Plan
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] 1.2.0 Release Plan
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] 1.2.0 Release Plan
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] 1.2.0 Release Plan
--- Ted Husted [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] 1.2.0 Release Plan
+1 David --- Ted Husted [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] 1.2.0 Release Plan
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] 1.2.0 Release Plan
+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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] 1.2.0 Release Plan
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: [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: [VOTE] 1.2.0 Release Plan
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: [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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] 1.2.0 Release Plan
+1 -Original Message- From: Ted Husted [mailto:[EMAIL PROTECTED] Sent: Tuesday, December 16, 2003 05:48 PM To: 'Struts Developers List' Subject: [VOTE] 1.2.0 Release Plan 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] 1.2.0 Release Plan
Quoting Martin Cooper [EMAIL PROTECTED]: 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: [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] - 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]
[Validator] was Re: [VOTE] 1.2.0 Release Plan
Ok, then with 'tomcat' reading of the rules, I can put the 1.1.1 back for limited testing and then say next week call for a vote on commons-validator to classify it. I confused the issue by calling it an Alpha instead of a RC. -Rob -Original Message- From: Craig R. McClanahan Quoting Martin Cooper [EMAIL PROTECTED]: 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: [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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For
Re: [VOTE] 1.2.0 Release Plan
Were we still planning on using Validator 1.1.1 when it is released ? It's getting a little confusing, since I removed it, and called for a release Vote. The vote isn't scheduled to complete until Sunday Noon. And Struts source will be frozed at Saturday Midnight. -Rob - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] 1.2.0 Release Plan
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: [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] - 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] 1.2.0 Release Plan
If we use the current Validator 1.1.1 JAR, and it becomes the final release, then we could vote on whether Struts 1.2.0 can also be a final or General Availability release. If this Validator 1.1.1 JAR does not make final, then the best we could do is mark ours would be beta (since it has a beta dependency). In the second case, once Commons Validator 1.1.1 does go final, we could just tag and roll Struts 1.2.1 and then vote on that. (Or, if the change between the Commons Validator 1.1.1 RC and final were trivial, we could just patch the distribution.) Regardless of what happens with the Validator, I would be (pleasantly) surprised if Struts 1.2.0 did make the General Availability grade. All I really want to do now is tap the keg on 1.2.x. The mean number of milestones for a Jakarta stable release seems to be five or six. So, it would not be unusual for us to get 1.2.4 before hitting a General Availability grade. -Ted. [EMAIL PROTECTED] wrote: Were we still planning on using Validator 1.1.1 when it is released ? It's getting a little confusing, since I removed it, and called for a release Vote. The vote isn't scheduled to complete until Sunday Noon. And Struts source will be frozed at Saturday Midnight. -Rob - 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] 1.2.0 Release Plan
--- Ted Husted [EMAIL PROTECTED] wrote: The mean number of milestones for a Jakarta stable release seems to be five or six. So, it would not be unusual for us to get 1.2.4 before hitting a General Availability grade. That could be because products using this versioning/release system don't spend as much time making sure it's bullet proof. Struts 1.2.0 isn't much different than 1.1 so it wouldn't surprise me if we reached GA before 5 or 6 point releases. David -Ted. [EMAIL PROTECTED] wrote: Were we still planning on using Validator 1.1.1 when it is released ? It's getting a little confusing, since I removed it, and called for a release Vote. The vote isn't scheduled to complete until Sunday Noon. And Struts source will be frozed at Saturday Midnight. -Rob - 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] __ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] 1.2.0 Release Plan
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- James Mitchell Software Developer / Struts Evangelist http://www.struts-atlanta.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] 1.2.0 Release Plan
+ 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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] 1.2.0 Release Plan
Ted Husted wrote: If we use the current Validator 1.1.1 JAR, and it becomes the final release, then we could vote on whether Struts 1.2.0 can also be a final or General Availability release. If you recall I believe we came to consensus on struts-dev that Validator can't go Beta or GA w/o being released via Struts, otherwise it wouldn't get enough testing IMHO to even warrant a vote being called. If this Validator 1.1.1 JAR does not make final, then the best we could do is mark ours would be beta (since it has a beta dependency). In the second case, once Commons Validator 1.1.1 does go final, we could just tag and roll Struts 1.2.1 and then vote on that. (Or, if the change between the Commons Validator 1.1.1 RC and final were trivial, we could just patch the distribution.) Regardless of what happens with the Validator, I would be (pleasantly) surprised if Struts 1.2.0 did make the General Availability grade. All I really want to do now is tap the keg on 1.2.x. The mean number of milestones for a Jakarta stable release seems to be five or six. So, it would not be unusual for us to get 1.2.4 before hitting a General Availability grade. -Ted. [EMAIL PROTECTED] wrote: Were we still planning on using Validator 1.1.1 when it is released ? It's getting a little confusing, since I removed it, and called for a release Vote. The vote isn't scheduled to complete until Sunday Noon. And Struts source will be frozed at Saturday Midnight. -Rob - 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]
