Re: [VOTE] Declare Struts 1.1b3 as Struts 1.1 RC1
Can you announce on general, user list and the server side (maybe tomcat list) that B3 has been designated RC and that plan is a try for final on or before 2/14? That is the lowest common denominator, the only thing I am adding is that I think it is has not been publicized to the user list that B3 is pretty much RC and to get going. It has not been released for so long that everyone is asleep. .V Martin Cooper wrote: On Sun, 19 Jan 2003, V. Cekvenich wrote: Ahh how hard is to release a nightly + 8 bugs as a RCx first or rename B3 as RC1? Perhaps surprisingly, other than fixing the 8 bugs, there really isn't that much difference. Renaming B3 to RC1 sounds simple, but in practice, it requires a fair amount of work. One day, I'll finish writing up the Struts release process, so that others can step up to the plate and know what they need to do. The trick is that I have to write it up in such a way as to encourage people to take it on, rather than scare them away... ;-) -- Martin Cooper I (and I suspect some other users) did not treat the B3 as I should. This kind of says to users its going out, and they have only a short time to test their apps. Normaly I test fast, but I did not test B3 (with clients apps or basicPortal, they both use a lot of areas of Struts together). Of course if a few of you tested, cool with me. Vic Ted Husted wrote: I'm sure that as soon as the eight remaining issues are duly cleared, Martin would be happy to a cut a beta 4. http://issues.apache.org/bugzilla/buglist.cgi?bug_status=UNCONFIRMEDbug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDbug_status=VERIFIEDemail1=emailtype1=substringemailassigned_to1=1email2=emailtype2=substringemailreporter2=1bugidtype=includebug_id=15736%2C16019%2C11021%2C15044%2C15799%2C15883%2C15913%2C16073%2C15816%2C15912%2C15916%2C15935%2C15969%2C16067%2C16104%2C16207changedin=votes=chfieldfrom=chfieldto=Nowchfieldvalue=product=Strutsversion=1.1+Beta+3short_desc=short_desc_type=allwordssubstrlong_desc=long_desc_type=allwordssubstrbug_file_loc=bug_file_loc_type=allwordssubstrkeywords=keywords_type=anywordsfield0-0-0=nooptype0-0-0=noopvalue0-0-0=cmdtype=doitnewqueryname=order=reuse+last+sort If that looks good, any of us could then suggest converting the beta 4 to a release candidate or even the final release. (And I would favor the latter.) -Ted. James Turner wrote: From: Ted Husted [mailto:[EMAIL PROTECTED]] Sent: Sunday, January 19, 2003 5:19 PM To: Struts Developers List Subject: Re: [VOTE] Declare Struts 1.1b3 as Struts 1.1 RC1 So, I'd say lets cut to the chase. Do B4, and if it's good, let's just go with it. If the fence sitters come up with anything once final ships, we go with an early Struts 1.1.1. Let's get the momentum up, and trust ourselves to do the right thing when the time comes. -Ted. Fine with me either way. I just wanna ship da puppy. You wanna run the vote? :-) I'm looking at 15044 as we speak. James -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [VOTE] Declare Struts 1.1b3 as Struts 1.1 RC1
I wouldn't have a problem with taking a recent nightly build and declaring it RC1. Is this the way we want to go? James Turner Owner Manager, Black Bear Software, LLC [EMAIL PROTECTED] Author: MySQL JSP Web Applications: Data Driven Programming Using Tomcat and MySQL ISBN 0672323095; SAMS, 2002 Co-Author: Struts Kick Start ISBN 0672324725; SAMS, 2002 Forthcoming: Java Server Faces Kick Start SAMS, Fall 2003 -Original Message- From: David M. Karr [mailto:[EMAIL PROTECTED]] Sent: Sunday, January 19, 2003 3:02 AM To: [EMAIL PROTECTED] Subject: Re: [VOTE] Declare Struts 1.1b3 as Struts 1.1 RC1 David == David M Karr [EMAIL PROTECTED] writes: David Is there an easy way to get the diffs or comments of all elements with commits David since the 1.1b3 tagging? If it's useful, I figured out how to get the diffs listing, at least, with: cvs rdiff -rSTRUTS_1_1_B3 jakarta-struts I still don't know how to get the commit comments listing, but that is less important, if we can see the diffs listing. Considering the output I get from this, and approximately 50 commits since 1.1b3 (according to Martin), I think using the 1.1b3 tag is not advisable. I can't judge whether having 21 open bugs is meaningful, as I'm sure some fraction of those will be unresolvable, or not practical to fix in the 1.1 timeframe. -- === David M. Karr ; Java/J2EE/XML/Unix/C++ [EMAIL PROTECTED] ; SCJP; SCWCD -- To unsubscribe, e-mail: mailto:struts-dev- [EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] Declare Struts 1.1b3 as Struts 1.1 RC1
Try out Ant's cvstagdiff task - there is even an XSL file to turn this into a nice report built into the Ant 1.5+ distribution. Details: http://jakarta.apache.org/ant/manual/CoreTasks/cvstagdiff.html Erik On Sunday, January 19, 2003, at 03:01 AM, David M. Karr wrote: David == David M Karr [EMAIL PROTECTED] writes: David Is there an easy way to get the diffs or comments of all elements with commits David since the 1.1b3 tagging? If it's useful, I figured out how to get the diffs listing, at least, with: cvs rdiff -rSTRUTS_1_1_B3 jakarta-struts I still don't know how to get the commit comments listing, but that is less important, if we can see the diffs listing. Considering the output I get from this, and approximately 50 commits since 1.1b3 (according to Martin), I think using the 1.1b3 tag is not advisable. I can't judge whether having 21 open bugs is meaningful, as I'm sure some fraction of those will be unresolvable, or not practical to fix in the 1.1 timeframe. -- === David M. Karr ; Java/J2EE/XML/Unix/C++ [EMAIL PROTECTED] ; SCJP; SCWCD -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] Declare Struts 1.1b3 as Struts 1.1 RC1
It was my original understanding that Struts-el lived in the contrib folder, as Craig mentioned he would do with Struts-JSF. One advantage of this is that Struts-el (and Struts-JSF) could have their own release cycle. In general, I would to see us position Struts as a model and view agnostic Controller. As alternatives like JSTL, JSF, XML/XLST, become more common place, we will want to move the Struts taglibs out of the core distribution and into an optional distribution. This implies that, in general, we should be trying to decouple taglib implementations 0from the main distribution. I would suggest that struts-el be packaged as a separate download from the Struts 1.1 core, on the grounds that * As I understand it, struts-el requires the JSTL which in turn requires servlet 2.3. Our technical minimum requirements for Struts 1.1 are still servlet 2.2. * Packaging struts-el separately conincides with the long-term view for the product. In general, I'd like to suggest that stop thinking of Struts as a one site fits all distribution, and starting thinking of it as a core, central controller that people can use with other products, like Struts-JSF, Struts-el, or the original Struts JSP taglib. As it stands, struts-el has been documented as a contribution and does not appear with the other developer guides (mea culpa). Making it a standalone distribution is just a matter of changing the build script. This would then allow David to make a new release of struts-el without forcing a new release of the core framework. So, I will have to join David Karr in casting a negative vote as to promoting the beta to a release candidate as it is now built, on the grounds that struts-el should be distributed separately. Of course, since this is a majority vote situation, http://jakarta.apache.org/site/decisions.html these -1s will not prevent a release, unless other committers change their vote. (My chance to veto the idea unilaterally was when the build.xml was first changed, but that boat has sailed :( -Ted. David M. Karr wrote: David == David M Karr [EMAIL PROTECTED] writes: David == David Graham [EMAIL PROTECTED] writes: David The only added attribute was cdata that defaults to true on the javascript David tag. I'd like to see this included in the release because it rounds out the David xhtml functionality. David We have yet to hear back from Martin if he is vetoing this change. If he does, David then I'll remove the attribute and always put a cdata section around the David javascript in xhtml mode. Obviously, I and other xhtml users would be David dissapointed. David And on that note, remember that we need to make sure that any attribute changes David in the base library get into Struts-EL. There were some attribute changes made David right before the 1.1b3 tagging, which was during a five day period when my David house was without power for 79 hours, so I wasn't able to get the associated David Struts-EL changes in until after 1.1b3 was tagged. I don't think that is a David real problem, but it will be a real problem if something like this happens for David the real release. I'm not sure this matters at this point, but if we're really voting on taking the 1.1b3 tag as rc1, I guess I'd -1 that, based on my previous comment. If we used 1.1b3, The html:link tag will have an action attribute, but the html-el:link tag will not. Is there an easy way to get the diffs or comments of all elements with commits since the 1.1b3 tagging? -- Ted Husted, Struts in Action http://husted.com/struts/book.html -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] Declare Struts 1.1b3 as Struts 1.1 RC1
Ted Husted wrote: Of course, since this is a majority vote situation, http://jakarta.apache.org/site/decisions.html these -1s will not prevent a release, unless other committers change their vote. (My chance to veto the idea unilaterally was when the build.xml was first changed, but that boat has sailed :( -Ted. Or other committers cast -1s for whatever reason (keep forgetting how many we are now :) It's now +4 (turner, craigmcc, jmitchell, dgraham) and -3 (dmkarr, mcooper, husted). -T. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] Declare Struts 1.1b3 as Struts 1.1 RC1
Regardless of what we do in this instance, could we clarify as a guideline 1) Whether Beta to Release candidate votes are on corresponding CVS tag. 2) Whether we want to go from the nightly build to a RC without an intervening beta. Whatever teams like Tomcat and Ant are doing would be fine with me, but its been some time since I subscribed to those DEV lists. -Ted. Rob Leland wrote: Didn't David add the cdata/comments to the Javascript Tag that he and Martin were talking about on Thursday. It seemed that there was still disagreement that was a good thing ? Would those end up in the RC1 from the head of the CVS tree or are we voting on the STRUTS_1_1_B3 tag to become directly RC1 -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- Ted Husted, Struts in Action http://husted.com/struts/book.html -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] Declare Struts 1.1b3 as Struts 1.1 RC1
James Turner wrote: I would suggest that struts-el be packaged as a separate download from the Struts 1.1 core, on the grounds that... I can take the alternate view, which is that because struts-el is in the contrib directory, it implicitly has lower standards for release quality that the core distro. From the user's POV, if its in the primary download, then it's part of the core distribution. And, AFIAK, Apache release quality is binary. It is or it isn't. There aren't any shades of grey in the moniker Release. -Ted. I also feel that, given that the changes made in the repository since 1.1b3 have all been bug fixes (with I think 1 or 2 extremely minor exceptions), recycling to another beta is just a good way to throw another couple of weeks onto the release cycle. I think that the idea of declaring an RC1 is more a statement of intent to deliver a finished product based substantially on what we have now in a very short timeframe, we already strongly suspect an RC2 would have to be delivered in mid-Feb to catch up bug fixes from RC1 once people start to examine the release seriously. Regardless of what we do in this instance, could we clarify as a guideline 1) Whether Beta to Release candidate votes are on corresponding CVS tag. Given that there have been bug fixes since 1.1b3, I'd say we'd want to base on nightly build. 2) Whether we want to go from the nightly build to a RC without an intervening beta. I don't see why not, we don't do betas between release candidates (i.e., we go directly from RC1 to RC2), so we should be able to go from 1.1b3 to RC1, especially as it's been almost entirely bug-fixes. I'll recycle the vote one last time to make things clear, and we'll see where the vote lie. James Turner Owner Manager, Black Bear Software, LLC [EMAIL PROTECTED] Author: MySQL JSP Web Applications: Data Driven Programming Using Tomcat and MySQL ISBN 0672323095; SAMS, 2002 Co-Author: Struts Kick Start ISBN 0672324725; SAMS, 2002 Forthcoming: Java Server Faces Kick Start SAMS, Fall 2003 -Original Message- It was my original understanding that Struts-el lived in the contrib folder, as Craig mentioned he would do with Struts-JSF. One advantage of this is that Struts-el (and Struts-JSF) could have their own release cycle. In general, I would to see us position Struts as a model and view agnostic Controller. As alternatives like JSTL, JSF, XML/XLST, become more common place, we will want to move the Struts taglibs out of the core distribution and into an optional distribution. This implies that, in general, we should be trying to decouple taglib implementations 0from the main distribution. * As I understand it, struts-el requires the JSTL which in turn requires servlet 2.3. Our technical minimum requirements for Struts 1.1 are still servlet 2.2. * Packaging struts-el separately conincides with the long-term view for the product. In general, I'd like to suggest that stop thinking of Struts as a one site fits all distribution, and starting thinking of it as a core, central controller that people can use with other products, like Struts-JSF, Struts-el, or the original Struts JSP taglib. As it stands, struts-el has been documented as a contribution and does not appear with the other developer guides (mea culpa). Making it a standalone distribution is just a matter of changing the build script. This would then allow David to make a new release of struts-el without forcing a new release of the core framework. So, I will have to join David Karr in casting a negative vote as to promoting the beta to a release candidate as it is now built, on the grounds that struts-el should be distributed separately. Of course, since this is a majority vote situation, http://jakarta.apache.org/site/decisions.html these -1s will not prevent a release, unless other committers change their vote. (My chance to veto the idea unilaterally was when the build.xml was first changed, but that boat has sailed :( -Ted. David M. Karr wrote: David == David M Karr [EMAIL PROTECTED] writes: David == David Graham [EMAIL PROTECTED] writes: David The only added attribute was cdata that defaults to true on the javascript David tag. I'd like to see this included in the release because it rounds out the David xhtml functionality. David We have yet to hear back from Martin if he is vetoing this change. If he does, David then I'll remove the attribute and always put a cdata section around the David javascript in xhtml mode. Obviously, I and other xhtml users would be David dissapointed. David And on that note, remember that we need to make sure that any attribute changes David in the base library get into Struts-EL. There were some attribute changes made David right before the 1.1b3 tagging, which was during a five day period when my David house was
Re: [VOTE] Declare Struts 1.1b3 as Struts 1.1 RC1
Ted == Ted Husted [EMAIL PROTECTED] writes: Ted As it stands, struts-el has been documented as a contribution and does not Ted appear with the other developer guides (mea culpa). Making it a standalone Ted distribution is just a matter of changing the build script. This would then Ted allow David to make a new release of struts-el without forcing a new release of Ted the core framework. You certainly can't take all the blame for the lack of Struts-EL documentation, I haven't given you very much to integrate. Ted So, I will have to join David Karr in casting a negative vote as to promoting Ted the beta to a release candidate as it is now built, on the grounds that Ted struts-el should be distributed separately. I guess my only problem with this argument is that Struts-EL releases have to be closely tied to Struts releases. It doesn't just use Struts, like other contributions, it's interface has to exactly mirror the Struts interface. Except for some occasional minor bugs I've found in Struts-EL, the only real changes I've had to make were to reflect changes to tag attributes in the base library. Once Struts 1.1 is released with Struts-EL, I'm not sure I'd want to make any more releases of Struts-EL, until the next Struts release (unless I find any non-interface problems). If I made a Struts-EL release reflecting changes to the Struts nightly build (after 1.1), then we'd have the situation of a Struts-EL release which had to be used with a nightly build of Struts, and not the latest release. -- === David M. Karr ; Java/J2EE/XML/Unix/C++ [EMAIL PROTECTED] ; SCJP; SCWCD -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] Declare Struts 1.1b3 as Struts 1.1 RC1
Martin Cooper wrote: Given that there have been around 50 commits since 1.1-b3, and there arecurrently 21 Bugzilla issues outstanding, in all honesty, I would find it hard to claim that 1.1-b3 is really a release candidate. I would prefer to take what we have now, or in a (very) short time from now, and call that a release candidate. Calling 1.1-b3 a release candidate is, in my opinion, tantamount to lowering our standards, or at leastappearing to do so in the eyes of our customer base. That is not a goodprecedent to set. First, sorry about all the Bugzilla activity, but I wanted to be sure we knew where we stood before trudging on. As it stands, we have 8 open issues against B3. http://issues.apache.org/bugzilla/buglist.cgi?bug_status=UNCONFIRMEDbug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDbug_status=VERIFIEDemail1=emailtype1=substringemailassigned_to1=1email2=emailtype2=substringemailreporter2=1bugidtype=includebug_id=15736%2C16019%2C11021%2C15044%2C15799%2C15883%2C15913%2C16073%2C15816%2C15912%2C15916%2C15935%2C15969%2C16067%2C16104%2C16207changedin=votes=chfieldfrom=chfieldto=Nowchfieldvalue=product=Strutsversion=1.1+Beta+3short_desc=short_desc_type=allwordssubstrlong_desc=long_desc_type=allwordssubstrbug_file_loc=bug_file_loc_type=allwordssubstrkeywords=keywords_type=anywordsfield0-0-0=nooptype0-0-0=noopvalue0-0-0=cmdtype=doitnewqueryname=order=reuse+last+sort I've reviewed the rest and marked anything that could wait without compromising quality as RESOLVE LATER against the nightly build. http://issues.apache.org/bugzilla/buglist.cgi?bug_status=RESOLVEDresolution=LATERemail1=emailtype1=substringemailassigned_to1=1email2=emailtype2=substringemailreporter2=1bugidtype=includebug_id=changedin=votes=chfieldfrom=chfieldto=Nowchfieldvalue=product=Strutsversion=Nightly+Buildshort_desc=short_desc_type=allwordssubstrlong_desc=long_desc_type=allwordssubstrbug_file_loc=bug_file_loc_type=allwordssubstrkeywords=keywords_type=anywordsfield0-0-0=nooptype0-0-0=noopvalue0-0-0=cmdtype=doitnewqueryname=order=Reuse+same+sort+as+last+time All but 3 are enhancements. Two of these can't be confirmed right now, and the other involves message resources in modules. It may be an enhancement, but I wasn't sure. My suggestion would be to schedule a Beta 4 against the nightly build, and then to not hesitate releasing B4 as Struts 1.1. final if it flies. The idea being we suspect that B4 is a defacto release candidate, and may go from B4 to Release, if appropriate. I think we have giving everyone fair warning about an upcoming release and we could just skip the Release Candidate stage if we can bring out a solid beta. One thing I would discourage would be cutting a Release Candidate if we strongly suspect that we will need another RC. One definition of Release Candidate is o Release candidate means we think this build is it, and will only change high priority bugs -- and API changes are totally verbotten. http://jakarta.apache.org/site/guides.html and I would not want to dilute this definition to mean anything less that a code base that we honestly believe is ready for release. I would much prefer to go from a Beta to a Release without a Release Candidate than to cut a Release Candidate if we do not honestly believe it is ready for prime time. -Ted. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [VOTE] Declare Struts 1.1b3 as Struts 1.1 RC1
Ted said (I just love that aliteration...): My suggestion would be to schedule a Beta 4 against the nightly build, and then to not hesitate releasing B4 as Struts 1.1. final if it flies. The idea being we suspect that B4 is a defacto release candidate, and may go from B4 to Release, if appropriate. The only different is that if we call it an RC, people who have been sitting on the fence waiting to adopt might actually try 1.1 and we can flush out any hidden bugs that are only uncovered by strenuous applications testing. One thing I would discourage would be cutting a Release Candidate if we strongly suspect that we will need another RC. I strongly suspect only because I trust in comrade Murphy, and that there's Always One More Bug. One definition of Release Candidate is o Release candidate means we think this build is it, and will only change high priority bugs -- and API changes are totally verbotten. I think that's where we are, aren't we? I wouldn't be shocked if an RC based on a currently nightly build couldn't become the final. Declaring it a release candidate is more a signal than anything, it says: The didling is done, we intend to release the final product very shortly, this might be it, start using it so you'll be ready. James -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] Declare Struts 1.1b3 as Struts 1.1 RC1
Be that as it may, there is not a strict technical requirement that any of the Struts taglibs be bundled in the core JAR or that the releases coincide with the release of the Action and Config packages. Is the struts-el taglib now actually broken because html:link gained a missing property? Or does it simply fail to meet one of our expectations for the taglib? I am of the opinion that all the taglibs should be packaged separately. In this way, that fixes and enhancements that do not affect the core Action and Config packages could be released more easily. The conventional taglibs have stayed put so far since they arguably do no harm and provide a convenience to a great many users. But we now have the situation where you would be obligated to vote against a release because changes to one package where not reflected in another package, which at this time lives in the contrib folder. I submit this that this is the type of coupling that MVC was invented to defeat, and that we not taking our own advice =:0) Craig plans on releasing the Struts-JSF tablib separately, why can't we do the same with Struts-EL? -Ted. David M. Karr wrote: I guess my only problem with this argument is that Struts-EL releases have to be closely tied to Struts releases. It doesn't just use Struts, like other contributions, it's interface has to exactly mirror the Struts interface. Except for some occasional minor bugs I've found in Struts-EL, the only real changes I've had to make were to reflect changes to tag attributes in the base library. Once Struts 1.1 is released with Struts-EL, I'm not sure I'd want to make any more releases of Struts-EL, until the next Struts release (unless I find any non-interface problems). If I made a Struts-EL release reflecting changes to the Struts nightly build (after 1.1), then we'd have the situation of a Struts-EL release which had to be used with a nightly build of Struts, and not the latest release. -- Ted Husted, Struts in Action http://husted.com/struts/book.html -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] Declare Struts 1.1b3 as Struts 1.1 RC1
Anyone still sitting on the fence at this point is probably going to sit there through the final release, or would poke around for weeks before looking at it. Personally, I say we fix the 8 issues, release B4, and if nothing critical comes up in a week or ten days, go to Struts 1.1 final. (Hey, how about that for a Valentine's Day present? =:0) I do believe that we have a high-quality release that fulfills the Apache standards. But, realistically, the codebase is closer to a Struts 2.0 release than Struts 1.1. Things are likely to come up after the final release, regardless of how many or few release candidates we publish. This codebase has been in a beta for going on a year, and five different books have been published about it. I should hope it's ready for prime time by this point =:0) So, I'd say lets cut to the chase. Do B4, and if it's good, let's just go with it. If the fence sitters come up with anything once final ships, we go with an early Struts 1.1.1. Let's get the momentum up, and trust ourselves to do the right thing when the time comes. -Ted. James Turner wrote: Ted said (I just love that aliteration...): My suggestion would be to schedule a Beta 4 against the nightly build, and then to not hesitate releasing B4 as Struts 1.1. final if it flies. The idea being we suspect that B4 is a defacto release candidate, and may go from B4 to Release, if appropriate. The only different is that if we call it an RC, people who have been sitting on the fence waiting to adopt might actually try 1.1 and we can flush out any hidden bugs that are only uncovered by strenuous applications testing. One thing I would discourage would be cutting a Release Candidate if we strongly suspect that we will need another RC. I strongly suspect only because I trust in comrade Murphy, and that there's Always One More Bug. One definition of Release Candidate is o Release candidate means we think this build is it, and will only change high priority bugs -- and API changes are totally verbotten. I think that's where we are, aren't we? I wouldn't be shocked if an RC based on a currently nightly build couldn't become the final. Declaring it a release candidate is more a signal than anything, it says: The didling is done, we intend to release the final product very shortly, this might be it, start using it so you'll be ready. James -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- Ted Husted, Struts in Action http://husted.com/struts/book.html -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [VOTE] Declare Struts 1.1b3 as Struts 1.1 RC1
From: Ted Husted [mailto:[EMAIL PROTECTED]] Sent: Sunday, January 19, 2003 5:19 PM To: Struts Developers List Subject: Re: [VOTE] Declare Struts 1.1b3 as Struts 1.1 RC1 So, I'd say lets cut to the chase. Do B4, and if it's good, let's just go with it. If the fence sitters come up with anything once final ships, we go with an early Struts 1.1.1. Let's get the momentum up, and trust ourselves to do the right thing when the time comes. -Ted. Fine with me either way. I just wanna ship da puppy. You wanna run the vote? :-) I'm looking at 15044 as we speak. James -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] Declare Struts 1.1b3 as Struts 1.1 RC1
Ted == Ted Husted [EMAIL PROTECTED] writes: Ted Is the struts-el taglib now actually broken because html:link gained a missing Ted property? Or does it simply fail to meet one of our expectations for the taglib? No, I certainly wouldn't call it broken, just that it wouldn't support an attribute that is supported in the base library. Ted I am of the opinion that all the taglibs should be packaged separately. In this Ted way, that fixes and enhancements that do not affect the core Action and Config Ted packages could be released more easily. The conventional taglibs have stayed Ted put so far since they arguably do no harm and provide a convenience to a great Ted many users. I suppose if core Struts was separated from the tag library, then both tag libraries could be released together in a single package. Ted But we now have the situation where you would be obligated to vote against a Ted release because changes to one package where not reflected in another package, Ted which at this time lives in the contrib folder. I submit this that this is the Ted type of coupling that MVC was invented to defeat, and that we not taking our Ted own advice =:0) The problem is that Struts-EL is not coupled with the MVC parts, just with the tag library. Ted Craig plans on releasing the Struts-JSF tablib separately, why can't we do the Ted same with Struts-EL? I don't know enough about what exactly Struts-JSF will be doing to really compare it, but I would guess that it won't be as intimately tied to the Struts MVC core or to the Struts tag library, which would make it logical to be released separately. My other concern about doing this is that we'll be changing the packaging structure of Struts, just before a release. I think I see some of your point about packaging the MVC core separately from the tag libraries, but I think the Struts tag library should be packaged with Struts-EL. In any case, I'm concerned about changing the release and packaging structure so close to a release. -- === David M. Karr ; Java/J2EE/XML/Unix/C++ [EMAIL PROTECTED] ; SCJP; SCWCD -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] Declare Struts 1.1b3 as Struts 1.1 RC1
On Sun, 19 Jan 2003, Ted Husted wrote: Date: Sun, 19 Jan 2003 06:42:26 -0500 From: Ted Husted [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Subject: Re: [VOTE] Declare Struts 1.1b3 as Struts 1.1 RC1 It was my original understanding that Struts-el lived in the contrib folder, as Craig mentioned he would do with Struts-JSF. One advantage of this is that Struts-el (and Struts-JSF) could have their own release cycle. In general, I would to see us position Struts as a model and view agnostic Controller. As alternatives like JSTL, JSF, XML/XLST, become more common place, we will want to move the Struts taglibs out of the core distribution and into an optional distribution. This implies that, in general, we should be trying to decouple taglib implementations 0from the main distribution. This approach makes sense to me -- and could pretty easily be adddressed i the roadmap item for 1.2 I just added on reorganizing the build process. I would suggest that struts-el be packaged as a separate download from the Struts 1.1 core, on the grounds that * As I understand it, struts-el requires the JSTL which in turn requires servlet 2.3. Our technical minimum requirements for Struts 1.1 are still servlet 2.2. * Packaging struts-el separately conincides with the long-term view for the product. Does it make sense to (perhaps also) have a contrib distribution that contains the latest released version of all the contrib packages at a given point in time? I'm going to be advocating for something similar for commons - and even created a package (commons-combo) that lets you combine your favorite released versions of all of them into a single JAR, with consolidated JavaDocs. In general, I'd like to suggest that stop thinking of Struts as a one site fits all distribution, and starting thinking of it as a core, central controller that people can use with other products, like Struts-JSF, Struts-el, or the original Struts JSP taglib. If you're also subscribed to STRUTS-USER, you've probably seen the recent uptick in interest around adding XML/web service support into Struts, and that would fit quite well with this philosophy. My only doubt would be on the timing ... doing this sort of thing now seems like just one more cause for delay to an audience that is getting increasingly impatient. Can we do the reorg changes in 1.2 / 2.0 instead? As it stands, struts-el has been documented as a contribution and does not appear with the other developer guides (mea culpa). Making it a standalone distribution is just a matter of changing the build script. This would then allow David to make a new release of struts-el without forcing a new release of the core framework. So, I will have to join David Karr in casting a negative vote as to promoting the beta to a release candidate as it is now built, on the grounds that struts-el should be distributed separately. Of course, since this is a majority vote situation, http://jakarta.apache.org/site/decisions.html these -1s will not prevent a release, unless other committers change their vote. (My chance to veto the idea unilaterally was when the build.xml was first changed, but that boat has sailed :( It's clearly not a good idea to formally label 1.1b3 as a release candidate if we're not in consensus. However, rather than continue discussing it, that energy would be better spent resolving the remaining bug reports :-). -Ted. Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] Declare Struts 1.1b3 as Struts 1.1 RC1
On 19 Jan 2003, David M. Karr wrote: I don't know enough about what exactly Struts-JSF will be doing to really compare it, but I would guess that it won't be as intimately tied to the Struts MVC core or to the Struts tag library, which would make it logical to be released separately. I have a pretty fair idea what it will look like :-). It's going to be intimately tied in the sense that it includes a specialized RequestProcessor, another tag library, and the glue code to hook in Faces -- in other words, roughly as intimate as struts-el or tiles is. However, I'm not sure whether that really counts as a reason to choose one packaging over another. After all, nearly any Struts-based application (as opposed to a Struts extension) is likely to be just as intimate. My other concern about doing this is that we'll be changing the packaging structure of Struts, just before a release. I think I see some of your point about packaging the MVC core separately from the tag libraries, but I think the Struts tag library should be packaged with Struts-EL. In any case, I'm concerned about changing the release and packaging structure so close to a release. At the moment, I'm opposed to changing the packaging in a 1.1 release time frame. If we were serious about it, there is *far* more work to do than just repacking struts-el (see my grumblings yesterday about build.xml). If we're not going to do it all, we shouldn't risk upsetting the stability we have right now. David M. Karr ; Java/J2EE/XML/Unix/C++ Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] Declare Struts 1.1b3 as Struts 1.1 RC1
I'm sure that as soon as the eight remaining issues are duly cleared, Martin would be happy to a cut a beta 4. http://issues.apache.org/bugzilla/buglist.cgi?bug_status=UNCONFIRMEDbug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDbug_status=VERIFIEDemail1=emailtype1=substringemailassigned_to1=1email2=emailtype2=substringemailreporter2=1bugidtype=includebug_id=15736%2C16019%2C11021%2C15044%2C15799%2C15883%2C15913%2C16073%2C15816%2C15912%2C15916%2C15935%2C15969%2C16067%2C16104%2C16207changedin=votes=chfieldfrom=chfieldto=Nowchfieldvalue=product=Strutsversion=1.1+Beta+3short_desc=short_desc_type=allwordssubstrlong_desc=long_desc_type=allwordssubstrbug_file_loc=bug_file_loc_type=allwordssubstrkeywords=keywords_type=anywordsfield0-0-0=nooptype0-0-0=noopvalue0-0-0=cmdtype=doitnewqueryname=order=reuse+last+sort If that looks good, any of us could then suggest converting the beta 4 to a release candidate or even the final release. (And I would favor the latter.) -Ted. James Turner wrote: From: Ted Husted [mailto:[EMAIL PROTECTED]] Sent: Sunday, January 19, 2003 5:19 PM To: Struts Developers List Subject: Re: [VOTE] Declare Struts 1.1b3 as Struts 1.1 RC1 So, I'd say lets cut to the chase. Do B4, and if it's good, let's just go with it. If the fence sitters come up with anything once final ships, we go with an early Struts 1.1.1. Let's get the momentum up, and trust ourselves to do the right thing when the time comes. -Ted. Fine with me either way. I just wanna ship da puppy. You wanna run the vote? :-) I'm looking at 15044 as we speak. James -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- Ted Husted, Struts in Action http://husted.com/struts/book.html -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] Declare Struts 1.1b3 as Struts 1.1 RC1
Ahh how hard is to release a nightly + 8 bugs as a RCx first or rename B3 as RC1? I (and I suspect some other users) did not treat the B3 as I should. This kind of says to users its going out, and they have only a short time to test their apps. Normaly I test fast, but I did not test B3 (with clients apps or basicPortal, they both use a lot of areas of Struts together). Of course if a few of you tested, cool with me. Vic Ted Husted wrote: I'm sure that as soon as the eight remaining issues are duly cleared, Martin would be happy to a cut a beta 4. http://issues.apache.org/bugzilla/buglist.cgi?bug_status=UNCONFIRMEDbug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDbug_status=VERIFIEDemail1=emailtype1=substringemailassigned_to1=1email2=emailtype2=substringemailreporter2=1bugidtype=includebug_id=15736%2C16019%2C11021%2C15044%2C15799%2C15883%2C15913%2C16073%2C15816%2C15912%2C15916%2C15935%2C15969%2C16067%2C16104%2C16207changedin=votes=chfieldfrom=chfieldto=Nowchfieldvalue=product=Strutsversion=1.1+Beta+3short_desc=short_desc_type=allwordssubstrlong_desc=long_desc_type=allwordssubstrbug_file_loc=bug_file_loc_type=allwordssubstrkeywords=keywords_type=anywordsfield0-0-0=nooptype0-0-0=noopvalue0-0-0=cmdtype=doitnewqueryname=order=reuse+last+sort If that looks good, any of us could then suggest converting the beta 4 to a release candidate or even the final release. (And I would favor the latter.) -Ted. James Turner wrote: From: Ted Husted [mailto:[EMAIL PROTECTED]] Sent: Sunday, January 19, 2003 5:19 PM To: Struts Developers List Subject: Re: [VOTE] Declare Struts 1.1b3 as Struts 1.1 RC1 So, I'd say lets cut to the chase. Do B4, and if it's good, let's just go with it. If the fence sitters come up with anything once final ships, we go with an early Struts 1.1.1. Let's get the momentum up, and trust ourselves to do the right thing when the time comes. -Ted. Fine with me either way. I just wanna ship da puppy. You wanna run the vote? :-) I'm looking at 15044 as we speak. James -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] Declare Struts 1.1b3 as Struts 1.1 RC1
On Sun, 19 Jan 2003, Ted Husted wrote: I'm sure that as soon as the eight remaining issues are duly cleared, Martin would be happy to a cut a beta 4. Well, my preference would be to call it RC1 at that point, since we really expect it to be the release unless anything drastic shows up. But yes, I'm game to do the RM thing. If we're going for RC1 (or B4, I suppose, if people feel insecure about RC1), I'd like us to agree on a tag date *before* I post a release plan this time. ;-) Unfortunately, due to day job work at this time, I'm not going to have much time to help kill the remaining bugs, and the tag and build will have to happen over a weekend. So should it be next weekend, the weekend after that, or when? -- Martin Cooper http://issues.apache.org/bugzilla/buglist.cgi?bug_status=UNCONFIRMEDbug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDbug_status=VERIFIEDemail1=emailtype1=substringemailassigned_to1=1email2=emailtype2=substringemailreporter2=1bugidtype=includebug_id=15736%2C16019%2C11021%2C15044%2C15799%2C15883%2C15913%2C16073%2C15816%2C15912%2C15916%2C15935%2C15969%2C16067%2C16104%2C16207changedin=votes=chfieldfrom=chfieldto=Nowchfieldvalue=product=Strutsversion=1.1+Beta+3short_desc=short_desc_type=allwordssubstrlong_desc=long_desc_type=allwordssubstrbug_file_loc=bug_file_loc_type=allwordssubstrkeywords=keywords_type=anywordsfield0-0-0=nooptype0-0-0=noopvalue0-0-0=cmdtype=doitnewqueryname=order=reuse+last+sort If that looks good, any of us could then suggest converting the beta 4 to a release candidate or even the final release. (And I would favor the latter.) -Ted. James Turner wrote: From: Ted Husted [mailto:[EMAIL PROTECTED]] Sent: Sunday, January 19, 2003 5:19 PM To: Struts Developers List Subject: Re: [VOTE] Declare Struts 1.1b3 as Struts 1.1 RC1 So, I'd say lets cut to the chase. Do B4, and if it's good, let's just go with it. If the fence sitters come up with anything once final ships, we go with an early Struts 1.1.1. Let's get the momentum up, and trust ourselves to do the right thing when the time comes. -Ted. Fine with me either way. I just wanna ship da puppy. You wanna run the vote? :-) I'm looking at 15044 as we speak. James -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- Ted Husted, Struts in Action http://husted.com/struts/book.html -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] Declare Struts 1.1b3 as Struts 1.1 RC1
On Sun, 19 Jan 2003, V. Cekvenich wrote: Ahh how hard is to release a nightly + 8 bugs as a RCx first or rename B3 as RC1? Perhaps surprisingly, other than fixing the 8 bugs, there really isn't that much difference. Renaming B3 to RC1 sounds simple, but in practice, it requires a fair amount of work. One day, I'll finish writing up the Struts release process, so that others can step up to the plate and know what they need to do. The trick is that I have to write it up in such a way as to encourage people to take it on, rather than scare them away... ;-) -- Martin Cooper I (and I suspect some other users) did not treat the B3 as I should. This kind of says to users its going out, and they have only a short time to test their apps. Normaly I test fast, but I did not test B3 (with clients apps or basicPortal, they both use a lot of areas of Struts together). Of course if a few of you tested, cool with me. Vic Ted Husted wrote: I'm sure that as soon as the eight remaining issues are duly cleared, Martin would be happy to a cut a beta 4. http://issues.apache.org/bugzilla/buglist.cgi?bug_status=UNCONFIRMEDbug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDbug_status=VERIFIEDemail1=emailtype1=substringemailassigned_to1=1email2=emailtype2=substringemailreporter2=1bugidtype=includebug_id=15736%2C16019%2C11021%2C15044%2C15799%2C15883%2C15913%2C16073%2C15816%2C15912%2C15916%2C15935%2C15969%2C16067%2C16104%2C16207changedin=votes=chfieldfrom=chfieldto=Nowchfieldvalue=product=Strutsversion=1.1+Beta+3short_desc=short_desc_type=allwordssubstrlong_desc=long_desc_type=allwordssubstrbug_file_loc=bug_file_loc_type=allwordssubstrkeywords=keywords_type=anywordsfield0-0-0=nooptype0-0-0=noopvalue0-0-0=cmdtype=doitnewqueryname=order=reuse+last+sort If that looks good, any of us could then suggest converting the beta 4 to a release candidate or even the final release. (And I would favor the latter.) -Ted. James Turner wrote: From: Ted Husted [mailto:[EMAIL PROTECTED]] Sent: Sunday, January 19, 2003 5:19 PM To: Struts Developers List Subject: Re: [VOTE] Declare Struts 1.1b3 as Struts 1.1 RC1 So, I'd say lets cut to the chase. Do B4, and if it's good, let's just go with it. If the fence sitters come up with anything once final ships, we go with an early Struts 1.1.1. Let's get the momentum up, and trust ourselves to do the right thing when the time comes. -Ted. Fine with me either way. I just wanna ship da puppy. You wanna run the vote? :-) I'm looking at 15044 as we speak. James -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [VOTE] Declare Struts 1.1b3 as Struts 1.1 RC1
Martin Cooper wrote: Perhaps surprisingly, other than fixing the 8 bugs, there really isn't that much difference. Renaming B3 to RC1 sounds simple, but in practice, it requires a fair amount of work. Make that 5 bugs... James -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] Declare Struts 1.1b3 as Struts 1.1 RC1
David Graham wrote: +1 Didn't David add the cdata/comments to the Javascript Tag that he and Martin were talking about on Thursday. It seemed that there was still disagreement that was a good thing ? Would those end up in the RC1 from the head of the CVS tree or are we voting on the STRUTS_1_1_B3 tag to become directly RC1 -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] Declare Struts 1.1b3 as Struts 1.1 RC1
David == David Graham [EMAIL PROTECTED] writes: David The only added attribute was cdata that defaults to true on the javascript David tag. I'd like to see this included in the release because it rounds out the David xhtml functionality. David We have yet to hear back from Martin if he is vetoing this change. If he does, David then I'll remove the attribute and always put a cdata section around the David javascript in xhtml mode. Obviously, I and other xhtml users would be David dissapointed. And on that note, remember that we need to make sure that any attribute changes in the base library get into Struts-EL. There were some attribute changes made right before the 1.1b3 tagging, which was during a five day period when my house was without power for 79 hours, so I wasn't able to get the associated Struts-EL changes in until after 1.1b3 was tagged. I don't think that is a real problem, but it will be a real problem if something like this happens for the real release. -- === David M. Karr ; Java/J2EE/XML/Unix/C++ [EMAIL PROTECTED] ; SCJP; SCWCD -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] Declare Struts 1.1b3 as Struts 1.1 RC1
David == David M Karr [EMAIL PROTECTED] writes: David == David Graham [EMAIL PROTECTED] writes: David The only added attribute was cdata that defaults to true on the javascript David tag. I'd like to see this included in the release because it rounds out the David xhtml functionality. David We have yet to hear back from Martin if he is vetoing this change. If he does, David then I'll remove the attribute and always put a cdata section around the David javascript in xhtml mode. Obviously, I and other xhtml users would be David dissapointed. David And on that note, remember that we need to make sure that any attribute changes David in the base library get into Struts-EL. There were some attribute changes made David right before the 1.1b3 tagging, which was during a five day period when my David house was without power for 79 hours, so I wasn't able to get the associated David Struts-EL changes in until after 1.1b3 was tagged. I don't think that is a David real problem, but it will be a real problem if something like this happens for David the real release. I'm not sure this matters at this point, but if we're really voting on taking the 1.1b3 tag as rc1, I guess I'd -1 that, based on my previous comment. If we used 1.1b3, The html:link tag will have an action attribute, but the html-el:link tag will not. Is there an easy way to get the diffs or comments of all elements with commits since the 1.1b3 tagging? -- === David M. Karr ; Java/J2EE/XML/Unix/C++ [EMAIL PROTECTED] ; SCJP; SCWCD -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] Declare Struts 1.1b3 as Struts 1.1 RC1
Is that a -1 for 1.1 or -1 for any release? Dave From: [EMAIL PROTECTED] (David M. Karr) Reply-To: Struts Developers List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: [VOTE] Declare Struts 1.1b3 as Struts 1.1 RC1 Date: 18 Jan 2003 13:13:43 -0800 David == David M Karr [EMAIL PROTECTED] writes: David == David Graham [EMAIL PROTECTED] writes: David The only added attribute was cdata that defaults to true on the javascript David tag. I'd like to see this included in the release because it rounds out the David xhtml functionality. David We have yet to hear back from Martin if he is vetoing this change. If he does, David then I'll remove the attribute and always put a cdata section around the David javascript in xhtml mode. Obviously, I and other xhtml users would be David dissapointed. David And on that note, remember that we need to make sure that any attribute changes David in the base library get into Struts-EL. There were some attribute changes made David right before the 1.1b3 tagging, which was during a five day period when my David house was without power for 79 hours, so I wasn't able to get the associated David Struts-EL changes in until after 1.1b3 was tagged. I don't think that is a David real problem, but it will be a real problem if something like this happens for David the real release. I'm not sure this matters at this point, but if we're really voting on taking the 1.1b3 tag as rc1, I guess I'd -1 that, based on my previous comment. If we used 1.1b3, The html:link tag will have an action attribute, but the html-el:link tag will not. Is there an easy way to get the diffs or comments of all elements with commits since the 1.1b3 tagging? -- === David M. Karr ; Java/J2EE/XML/Unix/C++ [EMAIL PROTECTED] ; SCJP; SCWCD -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] _ MSN 8 with e-mail virus protection service: 2 months FREE* http://join.msn.com/?page=features/virus -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] Declare Struts 1.1b3 as Struts 1.1 RC1
On 18 Jan 2003, David M. Karr wrote: David == David M Karr [EMAIL PROTECTED] writes: David == David Graham [EMAIL PROTECTED] writes: David The only added attribute was cdata that defaults to true on the javascript David tag. I'd like to see this included in the release because it rounds out the David xhtml functionality. David We have yet to hear back from Martin if he is vetoing this change. If he does, David then I'll remove the attribute and always put a cdata section around the David javascript in xhtml mode. Obviously, I and other xhtml users would be David dissapointed. David And on that note, remember that we need to make sure that any attribute changes David in the base library get into Struts-EL. There were some attribute changes made David right before the 1.1b3 tagging, which was during a five day period when my David house was without power for 79 hours, so I wasn't able to get the associated David Struts-EL changes in until after 1.1b3 was tagged. I don't think that is a David real problem, but it will be a real problem if something like this happens for David the real release. I'm not sure this matters at this point, but if we're really voting on taking the 1.1b3 tag as rc1, I guess I'd -1 that, based on my previous comment. If we used 1.1b3, The html:link tag will have an action attribute, but the html-el:link tag will not. Is there an easy way to get the diffs or comments of all elements with commits since the 1.1b3 tagging? I haven't tried it, but you should be able to use 'cvs log' or 'cvs diff' with a date range to obtain the checkin comments or diffs, respectively, since the code was tagged for the 1.1-b3 release (on 12/30/02). Also, you might be able to use the list archives to identify commit messages since the tag date. Being a pack rat myself, I have all the messages stashed away. ;-) -- Martin Cooper -- === David M. Karr ; Java/J2EE/XML/Unix/C++ [EMAIL PROTECTED] ; SCJP; SCWCD -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] Declare Struts 1.1b3 as Struts 1.1 RC1
David == David Graham [EMAIL PROTECTED] writes: David Is that a -1 for 1.1 or -1 for any release? David Dave I very much want to see a 1.1 release very soon, I just don't think the release candidate should be the 1.1b3 release. From: [EMAIL PROTECTED] (David M. Karr) I'm not sure this matters at this point, but if we're really voting on taking the 1.1b3 tag as rc1, I guess I'd -1 that, based on my previous comment. If we used 1.1b3, The html:link tag will have an action attribute, but the html-el:link tag will not. -- === David M. Karr ; Java/J2EE/XML/Unix/C++ [EMAIL PROTECTED] ; SCJP; SCWCD -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] Declare Struts 1.1b3 as Struts 1.1 RC1
+1 Craig On Fri, 17 Jan 2003, James Turner wrote: Date: Fri, 17 Jan 2003 20:00:23 -0500 From: James Turner [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: [VOTE] Declare Struts 1.1b3 as Struts 1.1 RC1 In line with Craig's note earlier tonight, and the semi-voting that is already going on under another subject, I thought I'd make it formal/binding. So: +1 if you agree that the Struts 1.3b3 release should be declared the initial release candidate for the 1.1 release, with an RC2 in early February and final release at the end of February. 0 if you have no opinion one way or the other. -1 if you believe there is something critical that needs to be done before we can create a release candidate. I believe this requires a lazy majority according to The Rules. James Turner Owner Manager, Black Bear Software, LLC [EMAIL PROTECTED] Author: MySQL JSP Web Applications: Data Driven Programming Using Tomcat and MySQL ISBN 0672323095; SAMS, 2002 Co-Author: Struts Kick Start ISBN 0672324725; SAMS, 2002 Forthcoming: Java Server Faces Kick Start SAMS, Fall 2003 -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] Declare Struts 1.1b3 as Struts 1.1 RC1
+1 -- James Mitchell - Original Message - From: James Turner [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, January 17, 2003 8:00 PM Subject: [VOTE] Declare Struts 1.1b3 as Struts 1.1 RC1 In line with Craig's note earlier tonight, and the semi-voting that is already going on under another subject, I thought I'd make it formal/binding. So: +1 if you agree that the Struts 1.3b3 release should be declared the initial release candidate for the 1.1 release, with an RC2 in early February and final release at the end of February. 0 if you have no opinion one way or the other. -1 if you believe there is something critical that needs to be done before we can create a release candidate. I believe this requires a lazy majority according to The Rules. James Turner Owner Manager, Black Bear Software, LLC [EMAIL PROTECTED] Author: MySQL JSP Web Applications: Data Driven Programming Using Tomcat and MySQL ISBN 0672323095; SAMS, 2002 Co-Author: Struts Kick Start ISBN 0672324725; SAMS, 2002 Forthcoming: Java Server Faces Kick Start SAMS, Fall 2003 -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
