edgar wrote: > I disagree. > > The most useful method of timing releases for both developers and users > Is when the features reach critical mass.
Edgar, I definately understand that upgrading is a pain. At work we are required to build all code from its sources, then we have to test etc. At the same time if releases are a little more frequent, then that would give you the option of upgrading every time, or skipping a release if you wanted. I skip ever other release with my Java IDE, just because I don't want to spend money every year for a small upgrade in functionality. At the same time some people will not use a release is it is marked beta, so by having smaller, quicker releases, more people are likely to upgrade and expose any remaining bugs in those features. This does create more work for the Struts release manager, just like the people who choose to upgrade struts itself. Both approaches have advantages and disadvantages. > >>The real underlying problem, which we should address in post 1.1, is >>that our releases have become too coarsely grained. Moving past 1.1, > > we > >>should try to release whenever a significant feature is added, rather >>than when the features reach some critical mass. > > >>-Ted. > > > > > -- > 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]>
