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]>
