And should anyone have an itch to scratch. http://jakarta.apache.org/struts/helping.html
Since this is a volunteer project, we are all our own customers. Many other products have people working on them as part of the paid jobs. ASFAIK, that's not happening with Struts right now. My sincere suggestion to the corporate teams that depend on Struts is that's it time to "step up to the plate". If ~you~ need a release out the door, it's up to *you* to see that it happens. Craig tells a story of a time when he needed Tomcat out the door so his team could use it. His son (bless his soul) said "Dad, you know Java, why don't you help." The rest, as they say, is history. http://jakarta.apache.org/site/getinvolved.html We've been putting more Comitters on the team, which should help put through the patches we already have, but we still need more developers submitting patches for other issues -- and especially *unit tests* to prove the issues are fixed. -Ted. 10/15/2002 7:53:44 PM, [EMAIL PROTECTED] wrote: > >To blatently steal words from my favorite book on development - The Cathedral and the >Bazaar by Erik Raymond >(http://www.tuxedo.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/). > >In the section where he describes the rise of Linux and how Linus Torvolds help Linux >achieve such wide adoption, he states his rule number 7 for open > source: > >"7. Release early. Release often. And listen to your customers." > > >For example, look at Tomcat release 4.0 > >v4.0 18-Sep-2001 >v4.0.1 29-Apr-2002 >v4.0.2 10-Feb-2002 >v4.0.3 02-Mar-2002 >v4.0.4 28-Mar-2002 >v4.0.5 24-Sep-2002 >v4.0.6 08-Oct-2002 > >(Some of the dates may be a bit off - I had to surf ViewCVS looking at old release >notes) > >All these are stable releases. 7 releases in just over a year. > >I'd wager that accellerating the release process for Struts would >accelerate its adoption by corporations - and provide a lot more clients to >help put shoes on the kids. Plus the rest of us could use the cool new >features as well. > >Ted Husted <[EMAIL PROTECTED]> on 10/15/2002 06:50:23 PM > >Please respond to "Struts Developers List" <[EMAIL PROTECTED]> > >To: Struts Developers List <[EMAIL PROTECTED]> >cc: (bcc: Kevin Bedell/Systems/USHO/SunLife) >Subject: Re: Future Release Suggestion > > >As Craig pointed out recently, we all really do this for our own use, and >if someone else can use it too, then >that's "icing on the cake". > >Most of the Committers are highly enough placed in their own organizations >that they can use the nightly build >if they have to. So, the pressure to make incremental releases has not been >so great. > >But a good portion of my income now comes from working with teams that are >prohibited from using betas or a >nightly build. So, to keep shoes on the kids, I'm going to need to work >toward more incremental releases, so >that my clients can use it (and so they can in turn use me ;0) > >But, yes, I think that down the road we will need to start looking for >reasons to cut a release. If we have >several releases a year, then there will be less pressure to slip in one >more "gotta have it", since the next >release won't be so far away. > >Of course, at this point the die is cast, and we need to debug the features >already promised. > >-Ted. > > >10/15/2002 6:35:28 PM, David Graham <[EMAIL PROTECTED]> wrote: > >>I think the problem is that some very heavy hitters were added into 1.1. >>Validator, sub modules, map backed form attributes, tiles, >RequestProcessor, >>Plugins, etc. are all new (AFAIK) to 1.1. This amount of change requires >>quite a while to accomplish. >> >>It may be beneficial in the future to address bug fixes and one big new >item >>per release. This way, production releases are more frequent. >> >>What do the comitters think? >> >>David >> >> >> >> >>>From: [EMAIL PROTECTED] >>>Reply-To: "Struts Users Mailing List" <[EMAIL PROTECTED]> >>>To: <[EMAIL PROTECTED]> >>>Subject: RE: Struts 1.1 Release >>>Date: Tue, 15 Oct 2002 23:25:40 +0100 >>> >>>I totally understand and agree with the release policy, but I think it's >>>worth remembering that a lot of these questions are driven by the >>>constraints of users' environments - e.g. in corporate environments like >>>ours, there any many people like myself continually fighting to get great >>>open source products like Struts into the organisation so that >development >>>teams can use them, and the latest versions of them. However, this has to >>>be done within the processes and policies that apply to any third party >>>software, commercial or otherwise. >>> >>>Specifically, in our case, I am the product owner of Struts here among >>>other products from the Apache family of projects here and it is my >>>responsibility to make the standard builds of Struts on our software >>>distribution servers so that development can reference this for use by >>>their applications, as must be done for all external software (it's an >>>audit point). However, in order to do this, I must get the new version >>>approved by a central department which is extremely difficult, if not >>>impossible for software that is tagged as beta regardless of the quality. >>>(Yes, you can imagine how commercial software vendors deal with this in >>>their versioning policy... :-( ) Therefore, all our applications are >>>currently stuck on v1.0.2 rather than the latest and greatest 1.1 >>>regardless of how stable it may be in practice. I know that we are not >>>alone in this kind of approach, and that this kind of situation and red >>>tape is the reality in big organisations... >>> >>>Working in one of our architecture teams, I advise application >development >>>teams in our area when it comes to working out and implementing their >>>roadmaps, and part of this requires the recommendation of technologies on >>>the basis of an understanding of when certain products such as Struts can >>>be made available for their use - this applies equally to any kind of >>>software. >>> >>>So I would be interested in hearing any suggestions about how we could >>>resolve the need for us to have a better understanding of how close we >are >>>to a final release of any given version, e.g. clearly listing the issues >>>that are preventing a release being deemed as 1.1 quality on the website? >>>Would it be possible to change the versioning policy so that more >non-beta >>>dot releases are made possible, since many components are known to have >no >>>issues? These are just some ideas - they may well not be workable but I >>>would like to know what could be done, since it is very frustrating for >me >>>and others like me to play with great "beta" products and rave about them >>>to colleagues, but not be able to make them available for use by their >>>applications - this ultimately results in a lack of interest and apathy >>>towards such products, which is a great shame given their quality. >>> >>>Hope something useful can come out of this! >>> >>>Best regards, >>> >>> >>>Kosh >>> >>> >-----Original Message----- >>> >From: Chappell, Simon P [mailto:[EMAIL PROTECTED]] >>> >Sent: 15 October 2002 22:58 >>> >To: Struts Users Mailing List >>> >Subject: RE: Struts 1.1 Release >>> > >>> > >>> >Were you subscribed to the mailing list earlier today when >>> >this was discussed? >>> > >>> >Struts 1.1 will be released when it's released. Period. No >>> >variation from that. >>> > >>> >That said, even the beta versions of Struts far exceed other >>> >software in terms of usefulness and reliability, so don't >>> >worry about formal release dates and just start using the thing. >>> > >>> >Simon >>> > >>> >----------------------------------------------------------------- >>> >Simon P. Chappell [EMAIL PROTECTED] >>> >Java Programming Specialist www.landsend.com >>> >Lands' End, Inc. (608) 935-4526 >>> > >>> > >>> >>-----Original Message----- >>> >>From: Bachan Sadanandan [mailto:[EMAIL PROTECTED]] >>> >>Sent: Tuesday, October 15, 2002 4:54 PM >>> >>To: Struts Users Mailing List >>> >>Subject: Struts 1.1 Release >>> >> >>> >> >>> >>Hi all, >>> >>Any idea when Struts 1.1 would be ready for Production .??? >>> >> >>> >>Thanks ! >>> >>Bachan >>> >> >>> >>-- >>> >>To unsubscribe, e-mail: >>> >><mailto:struts-user->[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]> >>> >>> >>>Visit our website at http://www.ubswarburg.com >>> >>>This message contains confidential information and is intended only >>>for the individual named. If you are not the named addressee you >>>should not disseminate, distribute or copy this e-mail. Please >>>notify the sender immediately by e-mail if you have received this >>>e-mail by mistake and delete this e-mail from your system. >>> >>>E-mail transmission cannot be guaranteed to be secure or error-free >>>as information could be intercepted, corrupted, lost, destroyed, >>>arrive late or incomplete, or contain viruses. The sender therefore >>>does not accept liability for any errors or omissions in the contents >>>of this message which arise as a result of e-mail transmission. If >>>verification is required please request a hard-copy version. This >>>message is provided for informational purposes and should not be >>>construed as a solicitation or offer to buy or sell any securities or >>>related financial instruments. >>> >>> >>>-- >>>To unsubscribe, e-mail: >>><mailto:[EMAIL PROTECTED]> >>>For additional commands, e-mail: >>><mailto:[EMAIL PROTECTED]> >> >> >>_________________________________________________________________ >>Internet access plans that fit your lifestyle -- join MSN. >>http://resourcecenter.msn.com/access/plans/default.asp >> >> >>-- >>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] >> > > > > > > > >--------------------------------------------------------------------------- >This e-mail message (including attachments, if any) is intended for the use >of the individual or entity to which it is addressed and may contain >information that is privileged, proprietary , confidential and exempt from >disclosure. If you are not the intended recipient, you are notified that >any dissemination, distribution or copying of this communication is >strictly prohibited. If you have received this communication in error, >please notify the sender and erase this e-mail message immediately. >--------------------------------------------------------------------------- > > > >-- >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]>
