On Wed, 13 Oct 2004 09:03:48 -0500, Hubert Rabago wrote:
>�I also believe that Struts can release more often that every 18
>�months, but I don't know if a new release every few weeks will
>�help. In some cases, I think it might hurt Struts, because it can
>�make things pretty confusing for users. �I can see it now on the
>�user list: User A: "I need help trying to make feature X work".
>�User B: "What version are you using?" User A: "1.2.y" User B: "For
>�1.2.x, this is what you do." User C: "For 1.2.z, this is what you
>�do." User A: "None of those work for me. �Anybody else?" ~ silence ~

The versions aren't going to drift that rapidly. What happens is that someone reports 
a problem and we fix it. But the fix is only available in the nightly build. The 
nightly builds are all "Alphas", and so, after submitting a fix, many people can't use 
it in their production applications. A product manager insists they use Struts 
out-of-the-box. (Sad but true.) But if version 1.2.y has the fix, then we are giving 
people opportunity to use the fix, rather than suffer in silence.


>�I know I don't contribute code (or at least the ones I do often
>�don't get accepted), but I try to at least help out on the user
>�list whenever I can, and it's easier when you only have three
>�versions to deal with: the current release (1.2.4), the previous
>�release (1.1), and the nightly build. �(Hmm... when did I start
>�thinking like the guy on the other end of a tech support line?)
>
>�I think if there are compelling new features, then a release is
>�merited. �Perhaps there aren't a lot because the committers don't
>�have a lot of itches to scratch, or patches they like to commit or
>�work on. Some of the users/lurkers might have, and if the
>�committers have enhancements they'd like to see patches for, maybe
>�being more vocal about them would up the contrib rate. �For
>�instance, Craig has mentioned config inheritance, so it's more than
>�likely now that someone could start on that, knowing that that
>�patch would have a bigger chance of acceptance than some random
>�enhancement request in bugzilla. �It could increase participation,
>�and in turn new features, and in turn the reasons for rolling
>�another release.

The "compelling new features" argument is what lead us to the 18 month release cycle. 
People kept wanting to get one more thing into the release. So the release gets pushed 
farther and farther out, encouraging people to try and get one more thing in, because 
the release cycle ha now become so long.

It's a viscous downward spiral, and it has to stop.

There are a great number of teams that can't use the nightly build. If we don't cut 
regular releases, problems we fixed months and even a year ago, don't make it back to 
our users. What's the point of doing all this, if most people can't use what we do for 
so long?


>�On the other hand, if an every-few-weeks release cycle becomes the
>�norm, I suggest we keep track of which version has which on the
>�Wiki, just to make it easier on the users. :)

We already bundle a good set of notes with every release, and I can guarantee that 
won't change.

http://struts.apache.org/userGuide/release-notes.html

The problem is that after 18 months, the notes are so long, that people give up trying 
to read them. :)

And, of course, as far as maintaining anything on the Wiki goes, we includes you. :)

-Ted.


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to