On Thu, Feb 21, 2008 at 7:03 PM, Brian Pontarelli <[EMAIL PROTECTED]> wrote:
> Don Brown wrote: > > Yes, you are missing my original point #2 - "We need to be able to do > > "alpha" releases to get new, experimental features into the community > > for testing." I need a way to create an alpha release for 2.1 to hand > > off to our community for feedback, but if all releases require a > > unique patch version, I'm forced to create 2.1.1, 2.1.2, 2.1.3, etc. > > > > Public API changes take a while and lots of feedback to really get > > right, so going six months without a release is not acceptable, IMO. > > > I think we will have to disagree on this point. From my perspective > these things are mutually exclusive. You can make experimental new > features and changes without breaking compatibility. It still comes down > to being pragmatic about your changes and ensuring things don't break > severely. However, I want to make it clear that I'm NOT advocating never > breaking compatibility. I just want a versioning scheme that ensures > tools can figure it out. > > As a separate question, why can't the scheme be changed for Struts 2 > specifically? I get a sense that everyone is saying, "don't even think > about changing it because it will never happen." If something isn't > working and there are better ways to handle things, isn't it our jobs as > engineers to fix them? Before you start such a discussion, I would suggest that you take the time to look back, in the archives, through the several years worth of discussions in that got us to the point we're at today, so that you _fully_ understand the context and the reasoning behind the scheme that we have now. I really, really don't want to rehash those discussions, because they are always very prolonged, they consume vast amounts of time, energy and enthusiasm, and they seriously eat into the real development effort because of that. I'd much prefer to see the team's effort go into making Struts the best that it can be rather than go off down that rat hole. The one tip I will give you before you head to the archives is that our process is basically the same as the ones used by HTTPD and Tomcat, two of the most long-standing projects in all of the ASF, so it's not something we made up off the top of our heads. It's been proven in the real world for more than a decade. All of that said, once you fully understand all of the history, and if you still feel you have a really compelling reason for the project to switch to another scheme, you are of course absolutely free to propose it. But do spend the time first, so that you realise what you are letting yourself - and the rest of us - in for, and expect to significantly slow down progress on the code until that discussion comes to closure. -- Martin Cooper > > -bp > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
