I think it will benefit everyone to read this three part piece on evolving APIs:
http://wiki.eclipse.org/index.php/Evolving_Java-based_APIs Paul On Thu, Feb 21, 2008 at 10:37 PM, Martin Cooper <[EMAIL PROTECTED]> wrote: > 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] > > > > >
