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