Re: Status of 2.0.6 (Re: [VOTE] Struts 2.0.5 Quality)
Rainer Hermanns hermanns at aixcept.de writes: both, XWork 2.0.1 and OGNL 2.6.10 were released and are available via the maven repository at OpenSymphony.com. I already updated the core/pom.xml for branch 2.0.X and trunk. One note for others using the OGNL dependency: The groupId changed to opensymphony. Is there a changelog detailing the updates to OGNL? I didn't see anything at ognl.org or the OpenSymphony OGNL site. Thanks! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Status of 2.0.6 (Re: [VOTE] Struts 2.0.5 Quality)
Nate, only WW-1615[1] was resolved... We already released version 2.6.11 cause there were some confusions after the initial code migration of OGNL to the SVN repo at OpenSymphony. For the next release, a lot more issues will be addressed. hth, Rainer [1] https://issues.apache.org/struts/browse/WW-1615 Rainer Hermanns hermanns at aixcept.de writes: both, XWork 2.0.1 and OGNL 2.6.10 were released and are available via the maven repository at OpenSymphony.com. I already updated the core/pom.xml for branch 2.0.X and trunk. One note for others using the OGNL dependency: The groupId changed to opensymphony. Is there a changelog detailing the updates to OGNL? I didn't see anything at ognl.org or the OpenSymphony OGNL site. Thanks! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Rainer Hermanns aixcept Neupforte 16 52062 Aachen - Germany w: http://aixcept.de/ t:+49-241-4012247 m: +49-170-3432912 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Status of 2.0.6 (Re: [VOTE] Struts 2.0.5 Quality)
Two questions: 1, when will 2.0.6 be released? 2, is one *-all.zip will be released in the distribution? On 2/14/07, Ted Husted [EMAIL PROTECTED] wrote: So, tonight is last call on 2.0.6. Please try to take a look at the TODO list, if you have a chance. * https://issues.apache.org/struts/secure/IssueNavigator.jspa?mode=hiderequestId=10764 A fix for WW-1711 that didn't break the tests (or updated tests) would be especially welcome! -Ted. On 2/13/07, Ted Husted [EMAIL PROTECTED] wrote: I'd like to go ahead and tag the 2.0.6 release on Thursday between 1pm and 3pm PST. If you have a chance to preview the build, please do so, since we've removed the dependencies on the new API. Any of the other simple changes on the Struts 2.0.6 list would be welcome as well, otherwise we can push these over to 2.0.7. -Ted. -- HTH, Ted. * http://www.husted.com/struts/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Status of 2.0.6 (Re: [VOTE] Struts 2.0.5 Quality)
If everything is in working order, I'll tag the build circa 13:00 PST today. The PMC will then decide whether to release the build. The build will be like the others, and include an -all distribution. On 2/15/07, Ted Husted [EMAIL PROTECTED] wrote: As mentioned on another thread, Rainer is creating new releases of OGNL and then XWork 2. Since he expects the new releases to be available in the next 24 hours, we might as well wait and include the new JARs in the Struts 2.0.6 release. I'm tied up tomorrow and Saturday, but Sunday, 18-Feb, would work. In the meantime, any bugfixes or conservative patches could be applied to the 2_0_X branch. $ svn co https://svn.apache.org/repos/asf/struts/struts2/branches/STRUTS_2_0_X Of course, the head is open for 2.1.x development, and we need to cross-apply any applicable fixes. On 2/18/07, Shuai Zheng [EMAIL PROTECTED] wrote: Two questions: 1, when will 2.0.6 be released? 2, is one *-all.zip will be released in the distribution? On 2/14/07, Ted Husted [EMAIL PROTECTED] wrote: So, tonight is last call on 2.0.6. Please try to take a look at the TODO list, if you have a chance. * https://issues.apache.org/struts/secure/IssueNavigator.jspa?mode=hiderequestId=10764 A fix for WW-1711 that didn't break the tests (or updated tests) would be especially welcome! -Ted. On 2/13/07, Ted Husted [EMAIL PROTECTED] wrote: I'd like to go ahead and tag the 2.0.6 release on Thursday between 1pm and 3pm PST. If you have a chance to preview the build, please do so, since we've removed the dependencies on the new API. Any of the other simple changes on the Struts 2.0.6 list would be welcome as well, otherwise we can push these over to 2.0.7. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Status of 2.0.6 (Re: [VOTE] Struts 2.0.5 Quality)
Ted, both, XWork 2.0.1 and OGNL 2.6.10 were released and are available via the maven repository at OpenSymphony.com. I already updated the core/pom.xml for branch 2.0.X and trunk. One note for others using the OGNL dependency: The groupId changed to opensymphony. -Rainer As mentioned on another thread, Rainer is creating new releases of OGNL and then XWork 2. Since he expects the new releases to be available in the next 24 hours, we might as well wait and include the new JARs in the Struts 2.0.6 release. I'm tied up tomorrow and Saturday, but Sunday, 18-Feb, would work. In the meantime, any bugfixes or conservative patches could be applied to the 2_0_X branch. $ svn co https://svn.apache.org/repos/asf/struts/struts2/branches/STRUTS_2_0_X Of course, the head is open for 2.1.x development, and we need to cross-apply any applicable fixes. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Rainer Hermanns aixcept Neupforte 16 52062 Aachen - Germany w: http://aixcept.de/ t:+49-241-4012247 m: +49-170-3432912 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Status of 2.0.6 (Re: [VOTE] Struts 2.0.5 Quality)
As mentioned on another thread, Rainer is creating new releases of OGNL and then XWork 2. Since he expects the new releases to be available in the next 24 hours, we might as well wait and include the new JARs in the Struts 2.0.6 release. I'm tied up tomorrow and Saturday, but Sunday, 18-Feb, would work. In the meantime, any bugfixes or conservative patches could be applied to the 2_0_X branch. $ svn co https://svn.apache.org/repos/asf/struts/struts2/branches/STRUTS_2_0_X Of course, the head is open for 2.1.x development, and we need to cross-apply any applicable fixes. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Status of 2.0.6 (Re: [VOTE] Struts 2.0.5 Quality)
I think the problem is that when the TLD is generated into the META-INF folder, maven already copied the resources to the target folder, so the new TLD doesn't make it into the jar file. We can change the output path to the target/class/META-INF, but maven doesn't create the META-INF folder if it is empty, so the annotations code fails to create the file. Is there anyway to force maven to create the META-INF folder? regards musachy On 2/11/07, Ted Husted [EMAIL PROTECTED] wrote: It is in the -sources JAR, though, but that maven folder is not. Weird. On 2/11/07, Ted Husted [EMAIL PROTECTED] wrote: From a clean Maven repository, and a clean checkout of the 2_0_x branch, with no TLD present, $ mvn clean install site -P all,alljars,pre-assembly does not generate a core JAR with a TLD for me. The Manifest.mf is under META-INF, along with the mysterious maven folder, but the not TLD. If I build it a second time, the TLD does appear, which implies it's picking up the TLD from the first build. -Ted. On 2/11/07, Musachy Barroso [EMAIL PROTECTED] wrote: Inside the META-INF folder inside the core jar, there is a maven folder. I don't remember that folder, is it supposed to be there? musachy On 2/11/07, Musachy Barroso [EMAIL PROTECTED] wrote: On 2/11/07, Ted Husted [EMAIL PROTECTED] wrote: On 2/11/07, Musachy Barroso [EMAIL PROTECTED] wrote: I'm not sure what you mean. If I delete the TLD and do: mvn compile on core, it generates the TLD. Try it from a clean checkout and look to see if the TLD is in the JAR. Clean checkout: mvn -o -Dmaven.test.skip=true -Pcore and the TLD is under META-INF in the jar, are you doing any other step? Meanwhile, we seem to have two tags (doubleselect and optiontransferselect) )with vacillating HTML docs. r506206 - td align=left valign=topSet the list key of the second attribute/td + td align=left valign=topThe key expression to use for second list/td r506210 - td align=left valign=topThe key expression to use for second list/td + td align=left valign=topSet the list key of the second attribute/td When I build it again, the patch comes out - td align=left valign=topSet the list key of the second attribute/td + td align=left valign=topThe key expression to use for second list/td I totally don't understand what is happening here. Every time I commit the latest HTML docs, they revert to an alternate form. Spooky. I will check it out. musachy -- Hey you! Would you help me to carry the stone? Pink Floyd -- Hey you! Would you help me to carry the stone? Pink Floyd -- HTH, Ted. * http://www.husted.com/struts/ -- HTH, Ted. * http://www.husted.com/struts/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Hey you! Would you help me to carry the stone? Pink Floyd
Re: Status of 2.0.6 (Re: [VOTE] Struts 2.0.5 Quality)
Make sure you have the META-INF folder in src/main/resources -- because resources are always processed. Musachy Barroso wrote: I think the problem is that when the TLD is generated into the META-INF folder, maven already copied the resources to the target folder, so the new TLD doesn't make it into the jar file. We can change the output path to the target/class/META-INF, but maven doesn't create the META-INF folder if it is empty, so the annotations code fails to create the file. Is there anyway to force maven to create the META-INF folder? regards musachy On 2/11/07, Ted Husted [EMAIL PROTECTED] wrote: It is in the -sources JAR, though, but that maven folder is not. Weird. On 2/11/07, Ted Husted [EMAIL PROTECTED] wrote: From a clean Maven repository, and a clean checkout of the 2_0_x branch, with no TLD present, $ mvn clean install site -P all,alljars,pre-assembly does not generate a core JAR with a TLD for me. The Manifest.mf is under META-INF, along with the mysterious maven folder, but the not TLD. If I build it a second time, the TLD does appear, which implies it's picking up the TLD from the first build. -Ted. On 2/11/07, Musachy Barroso [EMAIL PROTECTED] wrote: Inside the META-INF folder inside the core jar, there is a maven folder. I don't remember that folder, is it supposed to be there? musachy On 2/11/07, Musachy Barroso [EMAIL PROTECTED] wrote: On 2/11/07, Ted Husted [EMAIL PROTECTED] wrote: On 2/11/07, Musachy Barroso [EMAIL PROTECTED] wrote: I'm not sure what you mean. If I delete the TLD and do: mvn compile on core, it generates the TLD. Try it from a clean checkout and look to see if the TLD is in the JAR. Clean checkout: mvn -o -Dmaven.test.skip=true -Pcore and the TLD is under META-INF in the jar, are you doing any other step? Meanwhile, we seem to have two tags (doubleselect and optiontransferselect) )with vacillating HTML docs. r506206 - td align=left valign=topSet the list key of the second attribute/td + td align=left valign=topThe key expression to use for second list/td r506210 - td align=left valign=topThe key expression to use for second list/td + td align=left valign=topSet the list key of the second attribute/td When I build it again, the patch comes out - td align=left valign=topSet the list key of the second attribute/td + td align=left valign=topThe key expression to use for second list/td I totally don't understand what is happening here. Every time I commit the latest HTML docs, they revert to an alternate form. Spooky. I will check it out. musachy -- Hey you! Would you help me to carry the stone? Pink Floyd -- Hey you! Would you help me to carry the stone? Pink Floyd -- HTH, Ted. * http://www.husted.com/struts/ -- HTH, Ted. * http://www.husted.com/struts/ - 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: Status of 2.0.6 (Re: [VOTE] Struts 2.0.5 Quality)
On 2/15/07, Musachy Barroso [EMAIL PROTECTED] wrote: I think the problem is that when the TLD is generated into the META-INF folder, maven already copied the resources to the target folder, so the new TLD doesn't make it into the jar file. Sounds like the TLD is getting generated too late in the build lifecycle, then. What phase is the plugin execution bound to? We can change the output path to the target/class/META-INF, but maven doesn't create the META-INF folder if it is empty, so the annotations code fails to create the file. Is there anyway to force maven to create the META-INF folder? Shouldn't the plugin create the directory if it doesn't exist? -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Status of 2.0.6 (Re: [VOTE] Struts 2.0.5 Quality)
Sounds like the TLD is getting generated too late in the build lifecycle, then. What phase is the plugin execution bound to? compile Shouldn't the plugin create the directory if it doesn't exist? Should it create every subfolder on the specified path if they don't exist? We could do that, I just thought that if there was a way of telling maven to copy the META-INF folder (even if empty), it would be easier. regards musachy
Re: Status of 2.0.6 (Re: [VOTE] Struts 2.0.5 Quality)
So, tonight is last call on 2.0.6. Please try to take a look at the TODO list, if you have a chance. * https://issues.apache.org/struts/secure/IssueNavigator.jspa?mode=hiderequestId=10764 A fix for WW-1711 that didn't break the tests (or updated tests) would be especially welcome! -Ted. On 2/13/07, Ted Husted [EMAIL PROTECTED] wrote: I'd like to go ahead and tag the 2.0.6 release on Thursday between 1pm and 3pm PST. If you have a chance to preview the build, please do so, since we've removed the dependencies on the new API. Any of the other simple changes on the Struts 2.0.6 list would be welcome as well, otherwise we can push these over to 2.0.7. -Ted. -- HTH, Ted. * http://www.husted.com/struts/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Status of 2.0.6 (Re: [VOTE] Struts 2.0.5 Quality)
I'd like to go ahead and tag the 2.0.6 release on Thursday between 1pm and 3pm PST. If you have a chance to preview the build, please do so, since we've removed the dependencies on the new API. Any of the other simple changes on the Struts 2.0.6 list would be welcome as well, otherwise we can push these over to 2.0.7. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Struts 2.0.5 Quality
On 2/10/07, Wendy Smoak [EMAIL PROTECTED] wrote: On 2/10/07, Tom Schneider [EMAIL PROTECTED] wrote: Umm, it looks like the spring plugin jar isn't included. Someone on #struts mentioned this and I confirmed it by downloading struts-2.0.5-all.zip from the website and it's not in the lib directory. (All the other plugins are there) Am I crazy or is it really missing? If you've confirmed it, please open an issue against 2.0.5. The file is probably missing from the assembly descriptor. --Wendy Yes, both the Spring Plugin and Codebehind Plugin are missing from the assembly POM. Do we just want to (1) note this as a known issue, (2) branch on 2.0.5 and issue a 2.0.5.1 version of the lib and all distributions. (3) issue 2.0.6 from the 2.0.x branch. I could do any of these things today. If we do (3), I would first drop and recreate the 2.0.x tag from the 2.0.5 tag, so as to skip over the changes that broke the HEAD after 2.0.5 was tag. (Last time I branch the HEAD rather than a tag!) Another build issue is that the TLD is being rewritten during the assembly, I guess to reflect changes to the annotations. Should we be running an assembly before the tag first, to look for TLD updates, and checking those in, before continuing with the rest of the tag and roll? Index: struts-tags.tld === --- struts-tags.tld (revision 503710) +++ struts-tags.tld (working copy) @@ -2762,7 +2762,7 @@ namedoubleListKey/name requiredfalse/required rtexprvaluetrue/rtexprvalue - description![CDATA[Set the list key of the second attribute]]/description + description![CDATA[The key expression to use for second list]]/description /attribute attribute namedoubleListValue/name @@ -5270,7 +5270,7 @@ namedoubleListKey/name requiredfalse/required rtexprvaluetrue/rtexprvalue - description![CDATA[Set the list key of the second attribute]]/description + description![CDATA[The key expression to use for second list]]/description /attribute attribute namedoubleListValue/name - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Struts 2.0.5 Quality
On 2/11/07, Ted Husted [EMAIL PROTECTED] wrote: Yes, both the Spring Plugin and Codebehind Plugin are missing from the assembly POM. Do we just want to (1) note this as a known issue, (2) branch on 2.0.5 and issue a 2.0.5.1 version of the lib and all distributions. (3) issue 2.0.6 from the 2.0.x branch. I could do any of these things today. If we do (3), I would first drop and recreate the 2.0.x tag from the 2.0.5 tag, so as to skip over the changes that broke the HEAD after 2.0.5 was tag. (Last time I branch the HEAD rather than a tag!) My vote goes to (3) including re-branching 2.0.x from the 2.0.5 tag. Another build issue is that the TLD is being rewritten during the assembly, I guess to reflect changes to the annotations. Should we be running an assembly before the tag first, to look for TLD updates, and checking those in, before continuing with the rest of the tag and roll? I'm not familiar enough with this to comment. Does this mean we're checking a generated file into svn? -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Struts 2.0.5 Quality
On 2/11/07, Wendy Smoak [EMAIL PROTECTED] wrote: I'm not familiar enough with this to comment. Does this mean we're checking a generated file into svn? My understanding is the annotations are generating the TLD. We checked the TLD when we were having problems with the generation, but I don't know if we want to keep it checked in or not. We also checkin the HTML docs for the tags, at * struts2/core/src/site/resources/tags I believe for the benefit of the snippet macro. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Struts 2.0.5 Quality
The TLD is always generated. It was removed at some point, but when we had the problem with the annotations, it was added back until the problem would be fixed, so it can be removed now. musachy On 2/11/07, Ted Husted [EMAIL PROTECTED] wrote: On 2/11/07, Wendy Smoak [EMAIL PROTECTED] wrote: I'm not familiar enough with this to comment. Does this mean we're checking a generated file into svn? My understanding is the annotations are generating the TLD. We checked the TLD when we were having problems with the generation, but I don't know if we want to keep it checked in or not. We also checkin the HTML docs for the tags, at * struts2/core/src/site/resources/tags I believe for the benefit of the snippet macro. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Hey you! Would you help me to carry the stone? Pink Floyd
Status of 2.0.6 (Re: [VOTE] Struts 2.0.5 Quality)
I'm working on cleaning up the build issues with 2.0.5, with the hope of tagging and rolling 2.0.6. The only question is whether we want to roll 2.0.6 immediately, or wait a day or two to see what else comes in. I'd say if not today, then by, say, Thursday. I also added a Release Plan section to the foot of 2.0.6 Release Notes, so that we are in compliance with our bylaws: Release Plan * Struts 2.0.6 is a milestone version in the 2.0.x series. o There is yet to be a GA release in this series. * The Release Manager is Ted Husted. * The tag date for the release is yet to be determined. But, our copy on people does not seem to syncing with the copy on cwiki. The autoexport is working, but the rsync is lagging. I'll look into that too. -Ted. On 2/11/07, Wendy Smoak [EMAIL PROTECTED] wrote: On 2/11/07, Ted Husted [EMAIL PROTECTED] wrote: Yes, both the Spring Plugin and Codebehind Plugin are missing from the assembly POM. Do we just want to (1) note this as a known issue, (2) branch on 2.0.5 and issue a 2.0.5.1 version of the lib and all distributions. (3) issue 2.0.6 from the 2.0.x branch. I could do any of these things today. If we do (3), I would first drop and recreate the 2.0.x tag from the 2.0.5 tag, so as to skip over the changes that broke the HEAD after 2.0.5 was tag. (Last time I branch the HEAD rather than a tag!) My vote goes to (3) including re-branching 2.0.x from the 2.0.5 tag. Another build issue is that the TLD is being rewritten during the assembly, I guess to reflect changes to the annotations. Should we be running an assembly before the tag first, to look for TLD updates, and checking those in, before continuing with the rest of the tag and roll? I'm not familiar enough with this to comment. Does this mean we're checking a generated file into svn? -- Wendy On 2/11/07, Tom Schneider [EMAIL PROTECTED] wrote: I vote for creation of a 2.0.x branch. There's several issues from webwork that haven't been applied to the 2.0.x series and I'm sure there will be more that will need to be carried forward. Tom On 2/11/07, Musachy Barroso [EMAIL PROTECTED] wrote: The TLD is always generated. It was removed at some point, but when we had the problem with the annotations, it was added back until the problem would be fixed, so it can be removed now. musachy On 2/11/07, Ted Husted [EMAIL PROTECTED] wrote: On 2/11/07, Wendy Smoak [EMAIL PROTECTED] wrote: I'm not familiar enough with this to comment. Does this mean we're checking a generated file into svn? My understanding is the annotations are generating the TLD. We checked the TLD when we were having problems with the generation, but I don't know if we want to keep it checked in or not. We also checkin the HTML docs for the tags, at * struts2/core/src/site/resources/tags I believe for the benefit of the snippet macro. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Status of 2.0.6 (Re: [VOTE] Struts 2.0.5 Quality)
On 2/11/07, Musachy Barroso [EMAIL PROTECTED] wrote: The TLD is always generated. It was removed at some point, but when we had the problem with the annotations, it was added back until the problem would be fixed, so it can be removed now. There seems to be a timing problem with the TLD generation. If I run it without a TLD, the TLD is left out of the JAR on the first pass. If I build again, then the TLD is generated and included, but that implies it is the TLD from the prior pass, not the current pass. I'm thinking better that we take the chance of omitting the JAR (and hearing about it) than include a possibly obsolete TLD. OF course, the big fix is to resolve the timing issue, so that the JAR we build in the working copy is the one included in the JAR. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Status of 2.0.6 (Re: [VOTE] Struts 2.0.5 Quality)
I'm not sure what you mean. If I delete the TLD and do: mvn compile on core, it generates the TLD. musachy On 2/11/07, Ted Husted [EMAIL PROTECTED] wrote: On 2/11/07, Musachy Barroso [EMAIL PROTECTED] wrote: The TLD is always generated. It was removed at some point, but when we had the problem with the annotations, it was added back until the problem would be fixed, so it can be removed now. There seems to be a timing problem with the TLD generation. If I run it without a TLD, the TLD is left out of the JAR on the first pass. If I build again, then the TLD is generated and included, but that implies it is the TLD from the prior pass, not the current pass. I'm thinking better that we take the chance of omitting the JAR (and hearing about it) than include a possibly obsolete TLD. OF course, the big fix is to resolve the timing issue, so that the JAR we build in the working copy is the one included in the JAR. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Hey you! Would you help me to carry the stone? Pink Floyd
Re: Status of 2.0.6 (Re: [VOTE] Struts 2.0.5 Quality)
On 2/11/07, Musachy Barroso [EMAIL PROTECTED] wrote: I'm not sure what you mean. If I delete the TLD and do: mvn compile on core, it generates the TLD. Try it from a clean checkout and look to see if the TLD is in the JAR. Meanwhile, we seem to have two tags (doubleselect and optiontransferselect) )with vacillating HTML docs. r506206 - td align=left valign=topSet the list key of the second attribute/td + td align=left valign=topThe key expression to use for second list/td r506210 - td align=left valign=topThe key expression to use for second list/td + td align=left valign=topSet the list key of the second attribute/td When I build it again, the patch comes out - td align=left valign=topSet the list key of the second attribute/td + td align=left valign=topThe key expression to use for second list/td I totally don't understand what is happening here. Every time I commit the latest HTML docs, they revert to an alternate form. Spooky. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Status of 2.0.6 (Re: [VOTE] Struts 2.0.5 Quality)
On 2/11/07, Ted Husted [EMAIL PROTECTED] wrote: On 2/11/07, Musachy Barroso [EMAIL PROTECTED] wrote: I'm not sure what you mean. If I delete the TLD and do: mvn compile on core, it generates the TLD. Try it from a clean checkout and look to see if the TLD is in the JAR. Clean checkout: mvn -o -Dmaven.test.skip=true -Pcore and the TLD is under META-INF in the jar, are you doing any other step? Meanwhile, we seem to have two tags (doubleselect and optiontransferselect) )with vacillating HTML docs. r506206 - td align=left valign=topSet the list key of the second attribute/td + td align=left valign=topThe key expression to use for second list/td r506210 - td align=left valign=topThe key expression to use for second list/td + td align=left valign=topSet the list key of the second attribute/td When I build it again, the patch comes out - td align=left valign=topSet the list key of the second attribute/td + td align=left valign=topThe key expression to use for second list/td I totally don't understand what is happening here. Every time I commit the latest HTML docs, they revert to an alternate form. Spooky. I will check it out. musachy -- Hey you! Would you help me to carry the stone? Pink Floyd
Re: Status of 2.0.6 (Re: [VOTE] Struts 2.0.5 Quality)
Inside the META-INF folder inside the core jar, there is a maven folder. I don't remember that folder, is it supposed to be there? musachy On 2/11/07, Musachy Barroso [EMAIL PROTECTED] wrote: On 2/11/07, Ted Husted [EMAIL PROTECTED] wrote: On 2/11/07, Musachy Barroso [EMAIL PROTECTED] wrote: I'm not sure what you mean. If I delete the TLD and do: mvn compile on core, it generates the TLD. Try it from a clean checkout and look to see if the TLD is in the JAR. Clean checkout: mvn -o -Dmaven.test.skip=true -Pcore and the TLD is under META-INF in the jar, are you doing any other step? Meanwhile, we seem to have two tags (doubleselect and optiontransferselect) )with vacillating HTML docs. r506206 - td align=left valign=topSet the list key of the second attribute/td + td align=left valign=topThe key expression to use for second list/td r506210 - td align=left valign=topThe key expression to use for second list/td + td align=left valign=topSet the list key of the second attribute/td When I build it again, the patch comes out - td align=left valign=topSet the list key of the second attribute/td + td align=left valign=topThe key expression to use for second list/td I totally don't understand what is happening here. Every time I commit the latest HTML docs, they revert to an alternate form. Spooky. I will check it out. musachy -- Hey you! Would you help me to carry the stone? Pink Floyd -- Hey you! Would you help me to carry the stone? Pink Floyd
Re: Status of 2.0.6 (Re: [VOTE] Struts 2.0.5 Quality)
If you want to remove those maven files, you need to update the POM to include this: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-jar-plugin/artifactId configuration archive addMavenDescriptorfalse/addMavenDescriptor /archive /configuration /plugin Paul Musachy Barroso wrote: Inside the META-INF folder inside the core jar, there is a maven folder. I don't remember that folder, is it supposed to be there? musachy On 2/11/07, Musachy Barroso [EMAIL PROTECTED] wrote: On 2/11/07, Ted Husted [EMAIL PROTECTED] wrote: On 2/11/07, Musachy Barroso [EMAIL PROTECTED] wrote: I'm not sure what you mean. If I delete the TLD and do: mvn compile on core, it generates the TLD. Try it from a clean checkout and look to see if the TLD is in the JAR. Clean checkout: mvn -o -Dmaven.test.skip=true -Pcore and the TLD is under META-INF in the jar, are you doing any other step? Meanwhile, we seem to have two tags (doubleselect and optiontransferselect) )with vacillating HTML docs. r506206 - td align=left valign=topSet the list key of the second attribute/td + td align=left valign=topThe key expression to use for second list/td r506210 - td align=left valign=topThe key expression to use for second list/td + td align=left valign=topSet the list key of the second attribute/td When I build it again, the patch comes out - td align=left valign=topSet the list key of the second attribute/td + td align=left valign=topThe key expression to use for second list/td I totally don't understand what is happening here. Every time I commit the latest HTML docs, they revert to an alternate form. Spooky. I will check it out. musachy -- Hey you! Would you help me to carry the stone? Pink Floyd - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Status of 2.0.6 (Re: [VOTE] Struts 2.0.5 Quality)
Thanks Paul. My bad, I had never seen them before, Wendy told me about it. There is a problem on DoubleListUIBean, the setter and the getter methods for doubleListKey are annotated as tag attributes, leave the annotation on the setter and remove the one on the getter, I think that will do. regards musachy On 2/11/07, Paul Benedict [EMAIL PROTECTED] wrote: If you want to remove those maven files, you need to update the POM to include this: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-jar-plugin/artifactId configuration archive addMavenDescriptorfalse/addMavenDescriptor /archive /configuration /plugin Paul Musachy Barroso wrote: Inside the META-INF folder inside the core jar, there is a maven folder. I don't remember that folder, is it supposed to be there? musachy On 2/11/07, Musachy Barroso [EMAIL PROTECTED] wrote: On 2/11/07, Ted Husted [EMAIL PROTECTED] wrote: On 2/11/07, Musachy Barroso [EMAIL PROTECTED] wrote: I'm not sure what you mean. If I delete the TLD and do: mvn compile on core, it generates the TLD. Try it from a clean checkout and look to see if the TLD is in the JAR. Clean checkout: mvn -o -Dmaven.test.skip=true -Pcore and the TLD is under META-INF in the jar, are you doing any other step? Meanwhile, we seem to have two tags (doubleselect and optiontransferselect) )with vacillating HTML docs. r506206 - td align=left valign=topSet the list key of the second attribute/td + td align=left valign=topThe key expression to use for second list/td r506210 - td align=left valign=topThe key expression to use for second list/td + td align=left valign=topSet the list key of the second attribute/td When I build it again, the patch comes out - td align=left valign=topSet the list key of the second attribute/td + td align=left valign=topThe key expression to use for second list/td I totally don't understand what is happening here. Every time I commit the latest HTML docs, they revert to an alternate form. Spooky. I will check it out. musachy -- Hey you! Would you help me to carry the stone? Pink Floyd - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Hey you! Would you help me to carry the stone? Pink Floyd
Re: Status of 2.0.6 (Re: [VOTE] Struts 2.0.5 Quality)
From a clean Maven repository, and a clean checkout of the 2_0_x branch, with no TLD present, $ mvn clean install site -P all,alljars,pre-assembly does not generate a core JAR with a TLD for me. The Manifest.mf is under META-INF, along with the mysterious maven folder, but the not TLD. If I build it a second time, the TLD does appear, which implies it's picking up the TLD from the first build. -Ted. On 2/11/07, Musachy Barroso [EMAIL PROTECTED] wrote: Inside the META-INF folder inside the core jar, there is a maven folder. I don't remember that folder, is it supposed to be there? musachy On 2/11/07, Musachy Barroso [EMAIL PROTECTED] wrote: On 2/11/07, Ted Husted [EMAIL PROTECTED] wrote: On 2/11/07, Musachy Barroso [EMAIL PROTECTED] wrote: I'm not sure what you mean. If I delete the TLD and do: mvn compile on core, it generates the TLD. Try it from a clean checkout and look to see if the TLD is in the JAR. Clean checkout: mvn -o -Dmaven.test.skip=true -Pcore and the TLD is under META-INF in the jar, are you doing any other step? Meanwhile, we seem to have two tags (doubleselect and optiontransferselect) )with vacillating HTML docs. r506206 - td align=left valign=topSet the list key of the second attribute/td + td align=left valign=topThe key expression to use for second list/td r506210 - td align=left valign=topThe key expression to use for second list/td + td align=left valign=topSet the list key of the second attribute/td When I build it again, the patch comes out - td align=left valign=topSet the list key of the second attribute/td + td align=left valign=topThe key expression to use for second list/td I totally don't understand what is happening here. Every time I commit the latest HTML docs, they revert to an alternate form. Spooky. I will check it out. musachy -- Hey you! Would you help me to carry the stone? Pink Floyd -- Hey you! Would you help me to carry the stone? Pink Floyd -- HTH, Ted. * http://www.husted.com/struts/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Status of 2.0.6 (Re: [VOTE] Struts 2.0.5 Quality)
It is in the -sources JAR, though, but that maven folder is not. Weird. On 2/11/07, Ted Husted [EMAIL PROTECTED] wrote: From a clean Maven repository, and a clean checkout of the 2_0_x branch, with no TLD present, $ mvn clean install site -P all,alljars,pre-assembly does not generate a core JAR with a TLD for me. The Manifest.mf is under META-INF, along with the mysterious maven folder, but the not TLD. If I build it a second time, the TLD does appear, which implies it's picking up the TLD from the first build. -Ted. On 2/11/07, Musachy Barroso [EMAIL PROTECTED] wrote: Inside the META-INF folder inside the core jar, there is a maven folder. I don't remember that folder, is it supposed to be there? musachy On 2/11/07, Musachy Barroso [EMAIL PROTECTED] wrote: On 2/11/07, Ted Husted [EMAIL PROTECTED] wrote: On 2/11/07, Musachy Barroso [EMAIL PROTECTED] wrote: I'm not sure what you mean. If I delete the TLD and do: mvn compile on core, it generates the TLD. Try it from a clean checkout and look to see if the TLD is in the JAR. Clean checkout: mvn -o -Dmaven.test.skip=true -Pcore and the TLD is under META-INF in the jar, are you doing any other step? Meanwhile, we seem to have two tags (doubleselect and optiontransferselect) )with vacillating HTML docs. r506206 - td align=left valign=topSet the list key of the second attribute/td + td align=left valign=topThe key expression to use for second list/td r506210 - td align=left valign=topThe key expression to use for second list/td + td align=left valign=topSet the list key of the second attribute/td When I build it again, the patch comes out - td align=left valign=topSet the list key of the second attribute/td + td align=left valign=topThe key expression to use for second list/td I totally don't understand what is happening here. Every time I commit the latest HTML docs, they revert to an alternate form. Spooky. I will check it out. musachy -- Hey you! Would you help me to carry the stone? Pink Floyd -- Hey you! Would you help me to carry the stone? Pink Floyd -- HTH, Ted. * http://www.husted.com/struts/ -- HTH, Ted. * http://www.husted.com/struts/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Struts 2.0.5 Quality
Umm, it looks like the spring plugin jar isn't included. Someone on #struts mentioned this and I confirmed it by downloading struts-2.0.5-all.zip from the website and it's not in the lib directory. (All the other plugins are there) Am I crazy or is it really missing? Tom Ted Husted wrote: The Struts 2.0.5 test build is now available. Release notes: * http://struts.apache.org/2.x/docs/release-notes-205.html Distribution: * http://people.apache.org/builds/struts/2.0.5/ Maven 2 staging repository: * http://people.apache.org/builds/struts/2.0.5/m2-staging-repository/ If you have had a chance to review the test build, please respond with a vote on its quality: [ ] Leave at test build [ ] Alpha [ ] Beta [ ] General Availability (GA) Everyone who has tested the build is invited to vote. Votes by PMC members are considered binding. A vote passes if there are at least three binding +1s and more +1s than -1s. Please remember that a *binding* +1 for GA implies that you intend to support the release by applying patches and responding to posts to the user and dev lists. The vote will remain open for at least 72 hours, longer upon request. -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] Struts 2.0.5 Quality
--- Tom Schneider [EMAIL PROTECTED] wrote: Am I crazy or is it really missing? It wasn't in mine; I copied it from showcase again. Dave Any questions? Get answers on any topic at www.Answers.yahoo.com. Try it now. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Struts 2.0.5 Quality
On 2/10/07, Tom Schneider [EMAIL PROTECTED] wrote: Umm, it looks like the spring plugin jar isn't included. Someone on #struts mentioned this and I confirmed it by downloading struts-2.0.5-all.zip from the website and it's not in the lib directory. (All the other plugins are there) Am I crazy or is it really missing? If you've confirmed it, please open an issue against 2.0.5. The file is probably missing from the assembly descriptor. -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Struts 2.0.5 Quality
Haha! I couldve confirmed this a coupple days ago when I updated. I just assumed it was a missed jar. Ejnded up just grabbing it from the showcase example. Anyways it def should be included in thr full lib. Sent from my BlackBerry device on the Rogers Wireless Network -Original Message- From: Tom Schneider [EMAIL PROTECTED] Date: Sat, 10 Feb 2007 22:37:08 To:Struts Developers List dev@struts.apache.org Subject: Re: [VOTE] Struts 2.0.5 Quality Umm, it looks like the spring plugin jar isn't included. Someone on #struts mentioned this and I confirmed it by downloading struts-2.0.5-all.zip from the website and it's not in the lib directory. (All the other plugins are there) Am I crazy or is it really missing? Tom Ted Husted wrote: The Struts 2.0.5 test build is now available. Release notes: * http://struts.apache.org/2.x/docs/release-notes-205.html Distribution: * http://people.apache.org/builds/struts/2.0.5/ Maven 2 staging repository: * http://people.apache.org/builds/struts/2.0.5/m2-staging-repository/ If you have had a chance to review the test build, please respond with a vote on its quality: [ ] Leave at test build [ ] Alpha [ ] Beta [ ] General Availability (GA) Everyone who has tested the build is invited to vote. Votes by PMC members are considered binding. A vote passes if there are at least three binding +1s and more +1s than -1s. Please remember that a *binding* +1 for GA implies that you intend to support the release by applying patches and responding to posts to the user and dev lists. The vote will remain open for at least 72 hours, longer upon request. -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] Struts 2.0.5 Quality
[ ] Leave at test build [ ] Alpha [ X ] Beta [ ] General Availability (GA) cheers, Rainer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Struts 2.0.5 Quality
On 2/7/07, Martin Cooper [EMAIL PROTECTED] wrote: On 2/7/07, Ted Husted [EMAIL PROTECTED] wrote: * http://httpd.apache.org/dev/guidelines.html which also mentions that On some issues, this vote is only binding if the voter has tested the action on their own system(s). I would suggest that in terms of a vote on a GA release, this means that the voter is using the bits in production (eating our own dog food). Yes, well _suggesting_ that is fine; making it a requirement is not. FWIW, the language in recent vote threads makes me less likely to take the time to test, since I don't have Struts apps in production anymore. I think we all have different roles to play, and that a vote based on exercising the example apps and examining the distribution for adherence to ASF release guidelines is just as valuable as a vote saying that it's working in a production system. -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Struts 2.0.5 Quality
OK, after thee days, we have GA - Binding +1 Patrick Lightbody Beta - Binding +1 Rene Gielen +1 Alexandru Popescu +1 Ted Husted +1 Rainer Hermanns GA - Non Binding +1 Matt Raible +1 Philip Luppens +1 David H. DeWolf I've submitted the 2.0.5 release for mirroring, so we can update the releases page and make a public announcement in 24 hours. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Struts 2.0.5 Quality
On 2/7/07, Martin Cooper [EMAIL PROTECTED] wrote: which also mentions that On some issues, this vote is only binding if the voter has tested the action on their own system(s). I would suggest that in terms of a vote on a GA release, this means that the voter is using the bits in production (eating our own dog food). Yes, well _suggesting_ that is fine; making it a requirement is not. It wasn't my intention to make anything a requirement. Hey, since when does anyone listen to me? :) My main concern is that the people who are casting binding votes are also agreeing to support the release. I believe that an essential component of a quality commensurate with a release to a general audience are people who will available to support the release after it is marked GA. If a PMC member has essentially gone emeritus in terms of a particular release, then I would suggest that is better for that individual to abstain. Despite its name, the PMC is not a political body, but a working group, and we need to know which people in the group are ready, willing, and able to do the work. My suggestion would be that we adopt the habit of reminding people that A binding vote not only states an opinion, but means that the voter is agreeing to help do the work. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Struts 2.0.5 Quality
I was hoping after 2.0.4 that the ognl race condition issue would have been resolved. Jesse is ready to push the release out probably this evening, but give it a couple of days. For me, 2.0.5 came a bit too soon after 2.0.4. But overal, I think the framework itself is ready for GA. [ ] Leave at test build [ ] Alpha [ ] Beta [x] General Availability (GA) Cheers, Phil On 2/6/07, Don Brown [EMAIL PROTECTED] wrote: I disagree; you shouldn't vote beta just because you haven't ran the code in production. A beta vote should be reserved for the case where you don't believe the quality is at the level of a GA release, and there should be specific issues you can point to that you feel need to be resolved first. If you have downloaded the release, ran it through whatever tests you deem appropriate, and it passes with flying colors, then a GA vote is warranted. Don Ted Husted wrote: Beta is also an option :) On 2/6/07, Ian Roughley [EMAIL PROTECTED] wrote: +0 for GA. I have some testing code that looks good, but no production code that has been converted. /Ian - 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] -- iDTV System Engineer Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. - John F. Woods - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts Release Process (again) (was [VOTE] Struts 2.0.5 Quality)
On 2/7/07, Rene Gielen [EMAIL PROTECTED] wrote: Craig, So feature freeze and branch 2.0.x now, only fix reported bugs from beta tests and roll out the result as GA, while trunk moves on to 2.1.x, fully open for new features and whatever? IMO this would be the perfect way to go, you get a big +1 from me on this :) - Rene +1 I totally agree with this. Craig McClanahan schrieb: On 2/6/07, Don Brown [EMAIL PROTECTED] wrote: Alexandru Popescu wrote: I see two clear stages: - a product that is ready from developers point of view - a product that gets its users acceptance [...] That is definitely one of the lessons to be learned from the Struts 1.xexperience. Here's how we're applying that lesson in Shale land. The recent 1.0.4 release is the first one we felt had a snowball's chance at being voted GA quality, so as soon as we cut that release we also branched (SHALE_1_0_X), with the rule that only bugfixes (including non-invasive bugfixes backported from the trunk) would be committed here. The trunk was then opened for further new feature development (as well as bugfixes). Right now, it is tentatively labelled as 1.1.0-SNAPSHOT, but that could easily become 2.0.0-SNAPSHOT if we wanted to do major non-backwards-compatible changes. The net effect is that Struts could: * Create a branch totally focused on stabilization and bugfixes ... the only *point* is to create a GA-quality branch based on the current feature set. If 2.0.5 does not cut the mustard, just fix the reported bugs and try again (weeks instead of years later). * Avoid slowing down new feature development ... it continues on the trunk. * If 2.05 (say) got voted GA but a security vulnerability or critical bug were later discovered, an updated version could be turned around VERY quickly on the branch. Just fix the bad problems and release it. You don't have to worry about stabilizing all the new features that might have been added on the trunk, because they won't be present on the branch. (The MyFaces folks are currently paying the same price we paid in 1.x, because they are intermixing new features and bugfixes on the trunk -- hopefully they will learn the same lesson.) Branches are our friends. The fact that we didn't leverage them is the biggest thing we did wrong in Struts 1.x development, IMHO. I hope that the Struts 2 process can improve based on lessons learned from that experience. Don Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- iDTV System Engineer Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. - John F. Woods - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts Release Process (again) (was [VOTE] Struts 2.0.5 Quality)
On 2/7/07, mraible [EMAIL PROTECTED] wrote: I'm with Don here - IMO, Struts 2.0.1 was been usable for the general public True. And if we had a stable release of XWork 2 in September, I believe that we would have marked 2.0.1 GA. and the subsequent releases are all a result of Apache politics (or Mavenisms). Until January 8, when XWork 2.0.0 was released, none of the other builds were eligible for non-beta status, because XW was beta. There were other issues with the builds, but we would have worked around those very quickly if a GA had even been possible. (As we did for 2.0.4 and 2.0.5.) -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts Release Process (again) (was [VOTE] Struts 2.0.5 Quality)
On 2/7/07, Philip Luppens [EMAIL PROTECTED] wrote: On 2/7/07, Rene Gielen [EMAIL PROTECTED] wrote: Craig, So feature freeze and branch 2.0.x now, only fix reported bugs from beta tests and roll out the result as GA, while trunk moves on to 2.1.x, fully open for new features and whatever? IMO this would be the perfect way to go, you get a big +1 from me on this :) - Rene +1 I totally agree with this. Full +1 for this. ./alex -- .w( the_mindstorm )p. Craig McClanahan schrieb: On 2/6/07, Don Brown [EMAIL PROTECTED] wrote: Alexandru Popescu wrote: I see two clear stages: - a product that is ready from developers point of view - a product that gets its users acceptance [...] That is definitely one of the lessons to be learned from the Struts 1.xexperience. Here's how we're applying that lesson in Shale land. The recent 1.0.4 release is the first one we felt had a snowball's chance at being voted GA quality, so as soon as we cut that release we also branched (SHALE_1_0_X), with the rule that only bugfixes (including non-invasive bugfixes backported from the trunk) would be committed here. The trunk was then opened for further new feature development (as well as bugfixes). Right now, it is tentatively labelled as 1.1.0-SNAPSHOT, but that could easily become 2.0.0-SNAPSHOT if we wanted to do major non-backwards-compatible changes. The net effect is that Struts could: * Create a branch totally focused on stabilization and bugfixes ... the only *point* is to create a GA-quality branch based on the current feature set. If 2.0.5 does not cut the mustard, just fix the reported bugs and try again (weeks instead of years later). * Avoid slowing down new feature development ... it continues on the trunk. * If 2.05 (say) got voted GA but a security vulnerability or critical bug were later discovered, an updated version could be turned around VERY quickly on the branch. Just fix the bad problems and release it. You don't have to worry about stabilizing all the new features that might have been added on the trunk, because they won't be present on the branch. (The MyFaces folks are currently paying the same price we paid in 1.x, because they are intermixing new features and bugfixes on the trunk -- hopefully they will learn the same lesson.) Branches are our friends. The fact that we didn't leverage them is the biggest thing we did wrong in Struts 1.x development, IMHO. I hope that the Struts 2 process can improve based on lessons learned from that experience. Don Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- iDTV System Engineer Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. - John F. Woods - 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: Struts Release Process (again) (was [VOTE] Struts 2.0.5 Quality)
Rene Gielen wrote: Craig, So feature freeze and branch 2.0.x now, only fix reported bugs from beta tests and roll out the result as GA, while trunk moves on to 2.1.x, fully open for new features and whatever? IMO this would be the perfect way to go, you get a big +1 from me on this :) +1 As well. - Rene Craig McClanahan schrieb: On 2/6/07, Don Brown [EMAIL PROTECTED] wrote: Alexandru Popescu wrote: I see two clear stages: - a product that is ready from developers point of view - a product that gets its users acceptance [...] That is definitely one of the lessons to be learned from the Struts 1.xexperience. Here's how we're applying that lesson in Shale land. The recent 1.0.4 release is the first one we felt had a snowball's chance at being voted GA quality, so as soon as we cut that release we also branched (SHALE_1_0_X), with the rule that only bugfixes (including non-invasive bugfixes backported from the trunk) would be committed here. The trunk was then opened for further new feature development (as well as bugfixes). Right now, it is tentatively labelled as 1.1.0-SNAPSHOT, but that could easily become 2.0.0-SNAPSHOT if we wanted to do major non-backwards-compatible changes. The net effect is that Struts could: * Create a branch totally focused on stabilization and bugfixes ... the only *point* is to create a GA-quality branch based on the current feature set. If 2.0.5 does not cut the mustard, just fix the reported bugs and try again (weeks instead of years later). * Avoid slowing down new feature development ... it continues on the trunk. * If 2.05 (say) got voted GA but a security vulnerability or critical bug were later discovered, an updated version could be turned around VERY quickly on the branch. Just fix the bad problems and release it. You don't have to worry about stabilizing all the new features that might have been added on the trunk, because they won't be present on the branch. (The MyFaces folks are currently paying the same price we paid in 1.x, because they are intermixing new features and bugfixes on the trunk -- hopefully they will learn the same lesson.) Branches are our friends. The fact that we didn't leverage them is the biggest thing we did wrong in Struts 1.x development, IMHO. I hope that the Struts 2 process can improve based on lessons learned from that experience. Don Craig - 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] Struts 2.0.5 Quality
Ted Husted wrote: [ ] Leave at test build [ ] Alpha [ ] Beta [ X ] General Availability (GA) +1 GA Deployed and tested into our qa environment without any glitches. Moving to production soon without any reservations. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Struts 2.0.5 Quality
On 2/5/07, Ted Husted [EMAIL PROTECTED] wrote: [ ] Leave at test build [ ] Alpha [x] Beta [ ] General Availability (GA) We've had a lot of comments on the prior test builds, and so I do have confidence in the bits. But, I'd still like to have a brief ten-day beta period, to encourage wider testing and participation by the greater community in the release process. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Struts 2.0.5 Quality
On 2/5/07, Ted Husted [EMAIL PROTECTED] wrote: The Struts 2.0.5 test build is now available. Release notes: * http://struts.apache.org/2.x/docs/release-notes-205.html Distribution: * http://people.apache.org/builds/struts/2.0.5/ Maven 2 staging repository: * http://people.apache.org/builds/struts/2.0.5/m2-staging-repository/ If you have had a chance to review the test build, please respond with a vote on its quality: [ ] Leave at test build [ ] Alpha [ ] Beta [ ] General Availability (GA) Everyone who has tested the build is invited to vote. Votes by PMC members are considered binding. A vote passes if there are at least three binding +1s and more +1s than -1s. Please remember that a *binding* +1 for GA implies that you intend to support the release by applying patches and responding to posts to the user and dev lists. No, it implies no such thing. A binding +1 for GA is a statement that you believe that the code is of a quality commensurate with a release to a general audience. It is not an implication of personal support or anything else. Further, a determination of GA status is up to each PMC member to make, and does not require anything in the way of deployment, production usage, or anything else of the sort. -- Martin Cooper The vote will remain open for at least 72 hours, longer upon request. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Struts 2.0.5 Quality
On 2/7/07, Martin Cooper [EMAIL PROTECTED] wrote: No, it implies no such thing. A binding +1 for GA is a statement that you believe that the code is of a quality commensurate with a release to a general audience. It is not an implication of personal support or anything else. Further, a determination of GA status is up to each PMC member to make, and does not require anything in the way of deployment, production usage, or anything else of the sort. From our bylaws: The act of voting carries certain obligations. Voters are not only stating their opinion, they are also agreeing to help do the work. * http://struts.apache.org/dev/bylaws.html I would suggest that the work of a GA release includes helping by applying patches and answering posts to the user list. Our language is taken from the HTTPD guidelines * http://httpd.apache.org/dev/guidelines.html which also mentions that On some issues, this vote is only binding if the voter has tested the action on their own system(s). I would suggest that in terms of a vote on a GA release, this means that the voter is using the bits in production (eating our own dog food). The need for production testing is also mentioned in the HTTPD release guidelines. * http://httpd.apache.org/dev/release.html under How can an RM be confident in a release? Of course, it also says each committer is free to come up with their own personal voting guidelines, which is why I used the word implies rather than a more concrete term like means. If a PMC member is voting +1 on a GA, but hasn't used the release in production, or does not intend to support the release afterwards, personally, I'd like to know that, so that other volunteers are not left holding the bag. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Struts 2.0.5 Quality
On 2/7/07, Ted Husted [EMAIL PROTECTED] wrote: On 2/7/07, Martin Cooper [EMAIL PROTECTED] wrote: No, it implies no such thing. A binding +1 for GA is a statement that you believe that the code is of a quality commensurate with a release to a general audience. It is not an implication of personal support or anything else. Further, a determination of GA status is up to each PMC member to make, and does not require anything in the way of deployment, production usage, or anything else of the sort. From our bylaws: The act of voting carries certain obligations. Voters are not only stating their opinion, they are also agreeing to help do the work. * http://struts.apache.org/dev/bylaws.html I would suggest that the work of a GA release includes helping by applying patches and answering posts to the user list. In earlier Struts releases, we have taken this to mean that someone is willing to help produce the release. I don't see how that morphs into a commitment to support the release after the fact. Our language is taken from the HTTPD guidelines * http://httpd.apache.org/dev/guidelines.html which also mentions that On some issues, this vote is only binding if the voter has tested the action on their own system(s). I would suggest that in terms of a vote on a GA release, this means that the voter is using the bits in production (eating our own dog food). Yes, well _suggesting_ that is fine; making it a requirement is not. The need for production testing is also mentioned in the HTTPD release guidelines. * http://httpd.apache.org/dev/release.html under How can an RM be confident in a release? Of course, it also says each committer is free to come up with their own personal voting guidelines, which is why I used the word implies rather than a more concrete term like means. If a PMC member is voting +1 on a GA, but hasn't used the release in production, or does not intend to support the release afterwards, personally, I'd like to know that, so that other volunteers are not left holding the bag. Not everyone is in a position to use a release in production the way you suggest, and certainly not in the timeframe required for a release vote. What if I'm developing a product that won't ship for another year? Are you saying that I can't vote GA, even if I think it's a rock solid release, just because I can't ship a product built on it for another 12 months? I hope not. And what changed, and when, from the Struts 1 model? Back when I was the release manager for Struts 1.x, there were no statements about being in production before voting, and I certainly voted +1 for several releases on the basis of comprehensive testing that I'd performed, not whether I had it in production or not. Given that I was working on long-term products at the time (as I am now), there's no way I could have had it in production in time fr the vote anyway. -- Martin Cooper -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Struts 2.0.5 Quality
Ted Husted-3 wrote: The Struts 2.0.5 test build is now available. Release notes: * http://struts.apache.org/2.x/docs/release-notes-205.html Distribution: * http://people.apache.org/builds/struts/2.0.5/ Maven 2 staging repository: * http://people.apache.org/builds/struts/2.0.5/m2-staging-repository/ If you have had a chance to review the test build, please respond with a vote on its quality: Tested with AppFuse 2: [ ] Leave at test build [ ] Alpha [ ] Beta [X] General Availability (GA) Non-binding. Matt -- View this message in context: http://www.nabble.com/-VOTE--Struts-2.0.5-Quality-tf3175941.html#a8821923 Sent from the Struts - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Struts 2.0.5 Quality
+1 for GA - I'm using it in HostedQA now and it is working great. - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=62617messageID=121464#121464 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Struts 2.0.5 Quality
+0 for GA. I have some testing code that looks good, but no production code that has been converted. /Ian Ted Husted wrote: The Struts 2.0.5 test build is now available. Release notes: * http://struts.apache.org/2.x/docs/release-notes-205.html Distribution: * http://people.apache.org/builds/struts/2.0.5/ Maven 2 staging repository: * http://people.apache.org/builds/struts/2.0.5/m2-staging-repository/ If you have had a chance to review the test build, please respond with a vote on its quality: [ ] Leave at test build [ ] Alpha [ ] Beta [ ] General Availability (GA) Everyone who has tested the build is invited to vote. Votes by PMC members are considered binding. A vote passes if there are at least three binding +1s and more +1s than -1s. Please remember that a *binding* +1 for GA implies that you intend to support the release by applying patches and responding to posts to the user and dev lists. The vote will remain open for at least 72 hours, longer upon request. -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] Struts 2.0.5 Quality
Beta is also an option :) On 2/6/07, Ian Roughley [EMAIL PROTECTED] wrote: +0 for GA. I have some testing code that looks good, but no production code that has been converted. /Ian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Struts 2.0.5 Quality
I disagree; you shouldn't vote beta just because you haven't ran the code in production. A beta vote should be reserved for the case where you don't believe the quality is at the level of a GA release, and there should be specific issues you can point to that you feel need to be resolved first. If you have downloaded the release, ran it through whatever tests you deem appropriate, and it passes with flying colors, then a GA vote is warranted. Don Ted Husted wrote: Beta is also an option :) On 2/6/07, Ian Roughley [EMAIL PROTECTED] wrote: +0 for GA. I have some testing code that looks good, but no production code that has been converted. /Ian - 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] Struts 2.0.5 Quality
We might have to agree to disagree. I believe a beta vote is warranted when someone believes the code is ready for testing outside of the development group. Personally, I am not in favor of passing a set of bits straight to GA without a beta cycle, especially when a release series hasn't seen a GA release yet. The term General Availability should mean that we feel it is ready for us by the general public, not just that we were able to use it ourselves. Of course, other PMC members may have different viewpoints. Remember, voting beta now is not the final disposition. It simply means that we can announce the release to the user list and encourage wider testing. If the reports come back joyful, then we can decide to apply the GA stamp. In the meantime, we can continue to roll new releases. I'd be happy to run one every week or two, so long as there is something to put into the notes :) -Ted. On 2/6/07, Don Brown [EMAIL PROTECTED] wrote: I disagree; you shouldn't vote beta just because you haven't ran the code in production. A beta vote should be reserved for the case where you don't believe the quality is at the level of a GA release, and there should be specific issues you can point to that you feel need to be resolved first. If you have downloaded the release, ran it through whatever tests you deem appropriate, and it passes with flying colors, then a GA vote is warranted. Don Ted Husted wrote: Beta is also an option :) On 2/6/07, Ian Roughley [EMAIL PROTECTED] wrote: +0 for GA. I have some testing code that looks good, but no production code that has been converted. /Ian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Struts Release Process (again) (was [VOTE] Struts 2.0.5 Quality)
Well, two comments here. First, how many beta releases do we need before it is time for a GA? I think we've been at beta quality since 2.0.1 and, yes, it has been helpful to weed out issues, but now with several large applications running Struts 2 and no significant issues in JIRA, I think we are ready for GA. The second is a general comment about this new release process. I think you are right that we'll have to agree to disagree here, cause I've always disliked this idea of doing a release then voting on it later. If we are taking that backwards-looking approach even farther and basically automatically giving releases a beta label until some undetermined future date when we vote again, then I really must object. I can understand the value of a test build and vote a few days after to ensure that the release process went off smoothly and all the important bits are in there. I may not particularly like it, but I agree it is necessary. What I find disturbing is that we would make a habit of waiting till weeks/months after the fact to label it GA. If the release is built, we test it and find nothing wrong, I think we should label it GA and move on. If bugs are found after the fact, then let's roll another release. I'm concerned that the backwards-looking way of thinking will result in a project that very rarely gets anything out to its users. I think open source projects work best when they release early and often, even if they may find bugs in it later on. And before the comment is made that test builds or even beta releases _are_ following the release early/often pattern, it certainly isn't true for what I'd argue that is the majority of developers who can't touch a product without the GA label. I really hope we can find a productive balance between the need for stability and need to keep the project moving at a healthy pace. Let's not fall into the Struts 1 trap of being overly conservative, but instead get out quality releases quickly and often. Don Ted Husted wrote: We might have to agree to disagree. I believe a beta vote is warranted when someone believes the code is ready for testing outside of the development group. Personally, I am not in favor of passing a set of bits straight to GA without a beta cycle, especially when a release series hasn't seen a GA release yet. The term General Availability should mean that we feel it is ready for us by the general public, not just that we were able to use it ourselves. Of course, other PMC members may have different viewpoints. Remember, voting beta now is not the final disposition. It simply means that we can announce the release to the user list and encourage wider testing. If the reports come back joyful, then we can decide to apply the GA stamp. In the meantime, we can continue to roll new releases. I'd be happy to run one every week or two, so long as there is something to put into the notes :) -Ted. On 2/6/07, Don Brown [EMAIL PROTECTED] wrote: I disagree; you shouldn't vote beta just because you haven't ran the code in production. A beta vote should be reserved for the case where you don't believe the quality is at the level of a GA release, and there should be specific issues you can point to that you feel need to be resolved first. If you have downloaded the release, ran it through whatever tests you deem appropriate, and it passes with flying colors, then a GA vote is warranted. Don Ted Husted wrote: Beta is also an option :) On 2/6/07, Ian Roughley [EMAIL PROTECTED] wrote: +0 for GA. I have some testing code that looks good, but no production code that has been converted. /Ian - 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: Struts Release Process (again) (was [VOTE] Struts 2.0.5 Quality)
On 2/6/07, Don Brown [EMAIL PROTECTED] wrote: Well, two comments here. First, how many beta releases do we need before it is time for a GA? I think we've been at beta quality since 2.0.1 and, yes, it has been helpful to weed out issues, but now with several large applications running Struts 2 and no significant issues in JIRA, I think we are ready for GA. The second is a general comment about this new release process. I think you are right that we'll have to agree to disagree here, cause I've always disliked this idea of doing a release then voting on it later. If we are taking that backwards-looking approach even farther and basically automatically giving releases a beta label until some undetermined future date when we vote again, then I really must object. I can understand the value of a test build and vote a few days after to ensure that the release process went off smoothly and all the important bits are in there. I may not particularly like it, but I agree it is necessary. What I find disturbing is that we would make a habit of waiting till weeks/months after the fact to label it GA. If the release is built, we test it and find nothing wrong, I think we should label it GA and move on. If bugs are found after the fact, then let's roll another release. I'm concerned that the backwards-looking way of thinking will result in a project that very rarely gets anything out to its users. I think open source projects work best when they release early and often, even if they may find bugs in it later on. And before the comment is made that test builds or even beta releases _are_ following the release early/often pattern, it certainly isn't true for what I'd argue that is the majority of developers who can't touch a product without the GA label. I really hope we can find a productive balance between the need for stability and need to keep the project moving at a healthy pace. Let's not fall into the Struts 1 trap of being overly conservative, but instead get out quality releases quickly and often. Isn't a feature of the current release practice that you could vote a particular x.y.z release as beta now, but later hold another vote to upgrade it to GA status later (i.e. without requiring another release)? Don's success with it is great ... but that is only one data point. Having 10-50 people report back success would seem to mean it's time to go back and give that release a better report card. Don Craig Ted Husted wrote: We might have to agree to disagree. I believe a beta vote is warranted when someone believes the code is ready for testing outside of the development group. Personally, I am not in favor of passing a set of bits straight to GA without a beta cycle, especially when a release series hasn't seen a GA release yet. The term General Availability should mean that we feel it is ready for us by the general public, not just that we were able to use it ourselves. Of course, other PMC members may have different viewpoints. Remember, voting beta now is not the final disposition. It simply means that we can announce the release to the user list and encourage wider testing. If the reports come back joyful, then we can decide to apply the GA stamp. In the meantime, we can continue to roll new releases. I'd be happy to run one every week or two, so long as there is something to put into the notes :) -Ted. On 2/6/07, Don Brown [EMAIL PROTECTED] wrote: I disagree; you shouldn't vote beta just because you haven't ran the code in production. A beta vote should be reserved for the case where you don't believe the quality is at the level of a GA release, and there should be specific issues you can point to that you feel need to be resolved first. If you have downloaded the release, ran it through whatever tests you deem appropriate, and it passes with flying colors, then a GA vote is warranted. Don Ted Husted wrote: Beta is also an option :) On 2/6/07, Ian Roughley [EMAIL PROTECTED] wrote: +0 for GA. I have some testing code that looks good, but no production code that has been converted. /Ian - 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] Struts 2.0.5 Quality
I'm going to do more testing this week, but I think (fear?) I have a first opinion so far: [ ] Leave at test build [ ] Alpha [ x] Beta [ ] General Availability (GA) Especially, I think we're not at GA level, because I have already two concerns preventing me from seeing the required level of quality: - Today I filed WW-1711, which turned out to be a ducplicate of two already filed issues (and should now be fixed in SVN for 2.0.6). The issue is about select tag which does not show the already selected model value when form renders, if the model value is of any other type than String. I think this is something you can see as minor issue for a Beta release, but not for GA (I stumbled over it while doing a three view technology demo) - Regarding the discussion of doubled ServletRequestAware interface in api and core module, I can very much live with the general opinion that we don't need a GA quality api module so far - but I would like to see all classes and interfaces which users will most likely refer to to have proper naming and reside in proper package. IMO, at least for ServletRequestAware (maybe for others too) this is probably not the case - sooner or later org.apache.struts2.interceptor.ServletRequestAware has to be moved to org.apache.struts2.servlet.ServletRequestAware, if in a separated api module or simply in core module. But if we throw out a GA now, we commit on a certain api stability which I doubt we can guarantee in nearest future. So, before going GA, I'm +1 for reviewing most commonly used interfaces and classes to be at least stable regarding package naming and base contracts. If we would agree on this need, I would of course volunteer to participate in reviewing. - Rene Ted Husted schrieb: The Struts 2.0.5 test build is now available. Release notes: * http://struts.apache.org/2.x/docs/release-notes-205.html Distribution: * http://people.apache.org/builds/struts/2.0.5/ Maven 2 staging repository: * http://people.apache.org/builds/struts/2.0.5/m2-staging-repository/ If you have had a chance to review the test build, please respond with a vote on its quality: [ ] Leave at test build [ ] Alpha [ ] Beta [ ] General Availability (GA) Everyone who has tested the build is invited to vote. Votes by PMC members are considered binding. A vote passes if there are at least three binding +1s and more +1s than -1s. Please remember that a *binding* +1 for GA implies that you intend to support the release by applying patches and responding to posts to the user and dev lists. The vote will remain open for at least 72 hours, longer upon request. -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] Struts 2.0.5 Quality
I fully agree with Ted's explanation of vote meanings so [ ] Leave at test build [ ] Alpha [ x] Beta [ ] General Availability (GA) ./alex -- .w( the_mindstorm )p. On 2/7/07, Ted Husted [EMAIL PROTECTED] wrote: We might have to agree to disagree. I believe a beta vote is warranted when someone believes the code is ready for testing outside of the development group. Personally, I am not in favor of passing a set of bits straight to GA without a beta cycle, especially when a release series hasn't seen a GA release yet. The term General Availability should mean that we feel it is ready for us by the general public, not just that we were able to use it ourselves. Of course, other PMC members may have different viewpoints. Remember, voting beta now is not the final disposition. It simply means that we can announce the release to the user list and encourage wider testing. If the reports come back joyful, then we can decide to apply the GA stamp. In the meantime, we can continue to roll new releases. I'd be happy to run one every week or two, so long as there is something to put into the notes :) -Ted. On 2/6/07, Don Brown [EMAIL PROTECTED] wrote: I disagree; you shouldn't vote beta just because you haven't ran the code in production. A beta vote should be reserved for the case where you don't believe the quality is at the level of a GA release, and there should be specific issues you can point to that you feel need to be resolved first. If you have downloaded the release, ran it through whatever tests you deem appropriate, and it passes with flying colors, then a GA vote is warranted. Don Ted Husted wrote: Beta is also an option :) On 2/6/07, Ian Roughley [EMAIL PROTECTED] wrote: +0 for GA. I have some testing code that looks good, but no production code that has been converted. /Ian - 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: Struts Release Process (again) (was [VOTE] Struts 2.0.5 Quality)
On 2/7/07, Craig McClanahan [EMAIL PROTECTED] wrote: On 2/6/07, Don Brown [EMAIL PROTECTED] wrote: Well, two comments here. First, how many beta releases do we need before it is time for a GA? I think we've been at beta quality since 2.0.1 and, yes, it has been helpful to weed out issues, but now with several large applications running Struts 2 and no significant issues in JIRA, I think we are ready for GA. The second is a general comment about this new release process. I think you are right that we'll have to agree to disagree here, cause I've always disliked this idea of doing a release then voting on it later. If we are taking that backwards-looking approach even farther and basically automatically giving releases a beta label until some undetermined future date when we vote again, then I really must object. I can understand the value of a test build and vote a few days after to ensure that the release process went off smoothly and all the important bits are in there. I may not particularly like it, but I agree it is necessary. What I find disturbing is that we would make a habit of waiting till weeks/months after the fact to label it GA. If the release is built, we test it and find nothing wrong, I think we should label it GA and move on. If bugs are found after the fact, then let's roll another release. I'm concerned that the backwards-looking way of thinking will result in a project that very rarely gets anything out to its users. I think open source projects work best when they release early and often, even if they may find bugs in it later on. And before the comment is made that test builds or even beta releases _are_ following the release early/often pattern, it certainly isn't true for what I'd argue that is the majority of developers who can't touch a product without the GA label. I really hope we can find a productive balance between the need for stability and need to keep the project moving at a healthy pace. Let's not fall into the Struts 1 trap of being overly conservative, but instead get out quality releases quickly and often. Isn't a feature of the current release practice that you could vote a particular x.y.z release as beta now, but later hold another vote to upgrade it to GA status later (i.e. without requiring another release)? Don's success with it is great ... but that is only one data point. Having 10-50 people report back success would seem to mean it's time to go back and give that release a better report card. Don Craig Ted Husted wrote: We might have to agree to disagree. I believe a beta vote is warranted when someone believes the code is ready for testing outside of the development group. Personally, I am not in favor of passing a set of bits straight to GA without a beta cycle, especially when a release series hasn't seen a GA release yet. The term General Availability should mean that we feel it is ready for us by the general public, not just that we were able to use it ourselves. Of course, other PMC members may have different viewpoints. Remember, voting beta now is not the final disposition. It simply means that we can announce the release to the user list and encourage wider testing. If the reports come back joyful, then we can decide to apply the GA stamp. In the meantime, we can continue to roll new releases. I'd be happy to run one every week or two, so long as there is something to put into the notes :) -Ted. I see two clear stages: - a product that is ready from developers point of view - a product that gets its users acceptance An OSS project can take the same approach or not, and this is up to its management. However, I feel that a project that would like to be widely used cannot be labeled as released version without the user acceptance. I understand Don's concern about how these steps should be managed, but I think this is not a very complex process: - developer's ready version: beta - (after a scheduled period during which only fixes go in if necessary): GA. ./alex -- .w( the_mindstorm )p. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Struts 2.0.5 Quality
On 2/6/07, Rene Gielen [EMAIL PROTECTED] wrote: But if we throw out a GA now, we commit on a certain api stability which I doubt we can guarantee in nearest future. The new API is clearly marked experimental, and so I don't feel that we would be committing to anything. Worse case, we could roll to 2.1.x, and move on. But, as to the new API, I believe the current feeling is that we should send it to the sandbox for now, and revisit the issue after Guice stabilizes. Someone just needs to detangle it from the ObjectFactory first. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts Release Process (again) (was [VOTE] Struts 2.0.5 Quality)
On 2/6/07, Craig McClanahan [EMAIL PROTECTED] wrote: Isn't a feature of the current release practice that you could vote a particular x.y.z release as beta now, but later hold another vote to upgrade it to GA status later (i.e. without requiring another release)? Don's success with it is great ... but that is only one data point. Having 10-50 people report back success would seem to mean it's time to go back and give that release a better report card. Craig Yes, it is, and we've used the approach successfully with Struts 1.x. It's nothing new. We've been using it for years, and so has HTTPD, and Tomcat, and dozens of other projects. Voting 2.0.5 beta now doesn't mean that it will stay at beta. It just means that we will release it to the user list for wider testing. If the user testing goes well, we can just promote 2.0.5 to GA, and announce it again. Nothing changes except our opinion. In the meantime, we can continue to make fixes and add features, and roll 2.0.6 as soon as we like. Hopefully, 2.0.5 will go GA, and so will 2.0.6. We had several GA releases in the 1.2.x series. One thing I tried this time was to post the Quality vote the day the test build went up. Next time, I'd like to try rolling on a Thursday, so that we can hold the vote over the weekend, and maybe announce on Monday. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts Release Process (again) (was [VOTE] Struts 2.0.5 Quality)
Alexandru Popescu wrote: I see two clear stages: - a product that is ready from developers point of view - a product that gets its users acceptance An OSS project can take the same approach or not, and this is up to its management. However, I feel that a project that would like to be widely used cannot be labeled as released version without the user acceptance. I understand Don's concern about how these steps should be managed, but I think this is not a very complex process: - developer's ready version: beta - (after a scheduled period during which only fixes go in if necessary): GA. I would love it if we actually did this. Unfortunately, we don't do the second step, which is to have a scheduled period that allows fixes to go in if necessary. What we actually do is freeze the code in a test build, and put that through an undetermined period after which it may be reassessed. If any problems are found after the build, the whole process starts again. What this results in is a project that very, very rarely releases a GA release because issues are always found after the test build. If you don't believe me, look how often we put GA releases out with Struts 1 and that was with a code base that rarely saw any significant development/features. Imagine how long it would take us to get out a release on a very active project... Don - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts Release Process (again) (was [VOTE] Struts 2.0.5 Quality)
On 2/6/07, Don Brown [EMAIL PROTECTED] wrote: I would love it if we actually did this. Unfortunately, we don't do the second step, which is to have a scheduled period that allows fixes to go in if necessary. What we actually do is freeze the code in a test build, and put that through an undetermined period after which it may be reassessed. If any problems are found after the build, the whole process starts again. What this results in is a project that very, very rarely releases a GA release because issues are always found after the test build. If you don't believe me, look how often we put GA releases out with Struts 1 and that was with a code base that rarely saw any significant development/features. Imagine how long it would take us to get out a release on a very active project... We did the second steps several times with Struts 1.2.x. As to Struts 2.0.x, so far, 2.0.2 has been our one and only beta. Every other build has failed for reasons unrelated to quality. * 2.0.0 (24/Sep) - Early test build against XWork snapshot. * 2.0.1 (11/Oct) - Test build against XWork beta 1. * 2.0.2 (20/Oct) - Voted beta, mainly due to XWork beta status (which in turn was due to documentation issues, rather than code quality). * 2.0.3 (19/Jan) - Stayed at test status due to Maven build issues. * 2.0.4 (28/Jan) - Tabled at test build, mainly for documentation/licensing issues. * 2.0.5 (05/Feb) - Current build. IMHO, what hurt us was that we had to roll 2.0.2 against a XWork beta, and then we made aggressive changes to the codebases. Now that XWork is GA, we had four months of very active development, and gobs of new features that were not in the 2.0.2 release. If 2.0.2 had been able to go GA, I'd be suggesting that we roll over to the 2.1.x series. Of course, there are and will be issues with 2.0.5. There are always issues. But, that doesn't mean we can't vote it GA after we've given the rest of the community a bite at the apple. The question isn't whether we reach an arbitrary standard of quality, but whether other people are going to say Works for me! During the Struts 1.1.x series, we did tend to freeze the codebase, but I don't feel that we do that any more. I feel that 2.0.5 is tagged, and we can move on to 2.0.6, full steam ahead, and/or 2.1.x if someone is ready to work on the Dojo and Portlet plugins. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts Release Process (again) (was [VOTE] Struts 2.0.5 Quality)
On 2/6/07, Don Brown [EMAIL PROTECTED] wrote: Alexandru Popescu wrote: I see two clear stages: - a product that is ready from developers point of view - a product that gets its users acceptance An OSS project can take the same approach or not, and this is up to its management. However, I feel that a project that would like to be widely used cannot be labeled as released version without the user acceptance. I understand Don's concern about how these steps should be managed, but I think this is not a very complex process: - developer's ready version: beta - (after a scheduled period during which only fixes go in if necessary): GA. I would love it if we actually did this. Unfortunately, we don't do the second step, which is to have a scheduled period that allows fixes to go in if necessary. What we actually do is freeze the code in a test build, and put that through an undetermined period after which it may be reassessed. If any problems are found after the build, the whole process starts again. What this results in is a project that very, very rarely releases a GA release because issues are always found after the test build. If you don't believe me, look how often we put GA releases out with Struts 1 and that was with a code base that rarely saw any significant development/features. Imagine how long it would take us to get out a release on a very active project... That is definitely one of the lessons to be learned from the Struts 1.xexperience. Here's how we're applying that lesson in Shale land. The recent 1.0.4 release is the first one we felt had a snowball's chance at being voted GA quality, so as soon as we cut that release we also branched (SHALE_1_0_X), with the rule that only bugfixes (including non-invasive bugfixes backported from the trunk) would be committed here. The trunk was then opened for further new feature development (as well as bugfixes). Right now, it is tentatively labelled as 1.1.0-SNAPSHOT, but that could easily become 2.0.0-SNAPSHOT if we wanted to do major non-backwards-compatible changes. The net effect is that Struts could: * Create a branch totally focused on stabilization and bugfixes ... the only *point* is to create a GA-quality branch based on the current feature set. If 2.0.5 does not cut the mustard, just fix the reported bugs and try again (weeks instead of years later). * Avoid slowing down new feature development ... it continues on the trunk. * If 2.05 (say) got voted GA but a security vulnerability or critical bug were later discovered, an updated version could be turned around VERY quickly on the branch. Just fix the bad problems and release it. You don't have to worry about stabilizing all the new features that might have been added on the trunk, because they won't be present on the branch. (The MyFaces folks are currently paying the same price we paid in 1.x, because they are intermixing new features and bugfixes on the trunk -- hopefully they will learn the same lesson.) Branches are our friends. The fact that we didn't leverage them is the biggest thing we did wrong in Struts 1.x development, IMHO. I hope that the Struts 2 process can improve based on lessons learned from that experience. Don Craig
Re: Struts Release Process (again) (was [VOTE] Struts 2.0.5 Quality)
I'm with Don here - IMO, Struts 2.0.1 was been usable for the general public and the subsequent releases are all a result of Apache politics (or Mavenisms). ;-) Matt Ted Husted-3 wrote: On 2/6/07, Don Brown [EMAIL PROTECTED] wrote: I would love it if we actually did this. Unfortunately, we don't do the second step, which is to have a scheduled period that allows fixes to go in if necessary. What we actually do is freeze the code in a test build, and put that through an undetermined period after which it may be reassessed. If any problems are found after the build, the whole process starts again. What this results in is a project that very, very rarely releases a GA release because issues are always found after the test build. If you don't believe me, look how often we put GA releases out with Struts 1 and that was with a code base that rarely saw any significant development/features. Imagine how long it would take us to get out a release on a very active project... We did the second steps several times with Struts 1.2.x. As to Struts 2.0.x, so far, 2.0.2 has been our one and only beta. Every other build has failed for reasons unrelated to quality. * 2.0.0 (24/Sep) - Early test build against XWork snapshot. * 2.0.1 (11/Oct) - Test build against XWork beta 1. * 2.0.2 (20/Oct) - Voted beta, mainly due to XWork beta status (which in turn was due to documentation issues, rather than code quality). * 2.0.3 (19/Jan) - Stayed at test status due to Maven build issues. * 2.0.4 (28/Jan) - Tabled at test build, mainly for documentation/licensing issues. * 2.0.5 (05/Feb) - Current build. IMHO, what hurt us was that we had to roll 2.0.2 against a XWork beta, and then we made aggressive changes to the codebases. Now that XWork is GA, we had four months of very active development, and gobs of new features that were not in the 2.0.2 release. If 2.0.2 had been able to go GA, I'd be suggesting that we roll over to the 2.1.x series. Of course, there are and will be issues with 2.0.5. There are always issues. But, that doesn't mean we can't vote it GA after we've given the rest of the community a bite at the apple. The question isn't whether we reach an arbitrary standard of quality, but whether other people are going to say Works for me! During the Struts 1.1.x series, we did tend to freeze the codebase, but I don't feel that we do that any more. I feel that 2.0.5 is tagged, and we can move on to 2.0.6, full steam ahead, and/or 2.1.x if someone is ready to work on the Dojo and Portlet plugins. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/-VOTE--Struts-2.0.5-Quality-tf3175941.html#a8840543 Sent from the Struts - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts Release Process (again) (was [VOTE] Struts 2.0.5 Quality)
Craig, So feature freeze and branch 2.0.x now, only fix reported bugs from beta tests and roll out the result as GA, while trunk moves on to 2.1.x, fully open for new features and whatever? IMO this would be the perfect way to go, you get a big +1 from me on this :) - Rene Craig McClanahan schrieb: On 2/6/07, Don Brown [EMAIL PROTECTED] wrote: Alexandru Popescu wrote: I see two clear stages: - a product that is ready from developers point of view - a product that gets its users acceptance [...] That is definitely one of the lessons to be learned from the Struts 1.xexperience. Here's how we're applying that lesson in Shale land. The recent 1.0.4 release is the first one we felt had a snowball's chance at being voted GA quality, so as soon as we cut that release we also branched (SHALE_1_0_X), with the rule that only bugfixes (including non-invasive bugfixes backported from the trunk) would be committed here. The trunk was then opened for further new feature development (as well as bugfixes). Right now, it is tentatively labelled as 1.1.0-SNAPSHOT, but that could easily become 2.0.0-SNAPSHOT if we wanted to do major non-backwards-compatible changes. The net effect is that Struts could: * Create a branch totally focused on stabilization and bugfixes ... the only *point* is to create a GA-quality branch based on the current feature set. If 2.0.5 does not cut the mustard, just fix the reported bugs and try again (weeks instead of years later). * Avoid slowing down new feature development ... it continues on the trunk. * If 2.05 (say) got voted GA but a security vulnerability or critical bug were later discovered, an updated version could be turned around VERY quickly on the branch. Just fix the bad problems and release it. You don't have to worry about stabilizing all the new features that might have been added on the trunk, because they won't be present on the branch. (The MyFaces folks are currently paying the same price we paid in 1.x, because they are intermixing new features and bugfixes on the trunk -- hopefully they will learn the same lesson.) Branches are our friends. The fact that we didn't leverage them is the biggest thing we did wrong in Struts 1.x development, IMHO. I hope that the Struts 2 process can improve based on lessons learned from that experience. Don Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[VOTE] Struts 2.0.5 Quality
The Struts 2.0.5 test build is now available. Release notes: * http://struts.apache.org/2.x/docs/release-notes-205.html Distribution: * http://people.apache.org/builds/struts/2.0.5/ Maven 2 staging repository: * http://people.apache.org/builds/struts/2.0.5/m2-staging-repository/ If you have had a chance to review the test build, please respond with a vote on its quality: [ ] Leave at test build [ ] Alpha [ ] Beta [ ] General Availability (GA) Everyone who has tested the build is invited to vote. Votes by PMC members are considered binding. A vote passes if there are at least three binding +1s and more +1s than -1s. Please remember that a *binding* +1 for GA implies that you intend to support the release by applying patches and responding to posts to the user and dev lists. The vote will remain open for at least 72 hours, longer upon request. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
