This one looks good a good resource. Sun also has one here:
http://java.sun.com/docs/books/jls/second_edition/html/binaryComp.doc.html
Section 13.4 of the java language specification covers compatibility
stuff. Sun also has some good information about versioning of JAR files
and distributed objects, which apply equally as well.
-bp
Paul Benedict wrote:
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
