The API has yet to be solidified and there are a few things that I'd
still like to discuss and possibly change in that regard. My main goal
is to ensure backwards compatibility in the convention plugin API.
My thinking is like this:
upgrading from [today's convention-plugin] to [final convention-plugin]
will be much easier than upgrading from [codebehind] to the [final
convention-plugin].
True. The changes will probably not impact most applications, but will
be API changes and not compatible.
Furthermore, I think we should all start thinking about when the "true"
stable release of XWork and Struts2 will be.
Isn't a GA release meant to be a "true stable release"?
I think to know what you want to say, but I am still somewhat confused about
why releases in s2 are working the way they do.
It depends on your versioning system. I prefer for all minor numbers
(2.x) to be compatible and all major numbers (x.0) to be incompatible
for the API perspective. I also feel that patches numbers (2.1.x) should
not add or subtract features. Therefore, the schema I use GAs don't
measure compatibility, the version numbers to. In my world you release
GAs for majors, minors and patches when they are final. If the release
isn't final, it uses a signifier like A, B, RC, M. For example,
2.1.1-RC1 would be the first release candidate and 2.1.1 would be the GA
final release. Struts versioning is much different though.
I think it makes sense to
target the next release and jump up to 2.5 or some number to indicate
stable APIs. This would include a number of API clean-ups, OGNL
replacement and a few other things that will severely break plugins and
applications. After that release, API changes should be compatible so
that plugins and applications can be upgraded without requiring
re-compiling.
I am quite sure there will rise another list with new issues that should be
resolved before a "true" release in some time...
In my oppinion, API stability is nothing that comes with reaching some feature
set or project milestone. This would imply stopping innovation at that point.
For me, API stability needs to be some kind of project goal or philosophy -
which needs to be enforced by defining commonly accepted rules.
I agree for the most part, but also use version numbers to imply API
freeze and compatibility. Innovation and API compatibility are not
mutually exclusive. Folks just have to understand what they can and
cannot do to APIs. For example, you cannot remove any methods or classes
otherwise, it isn't compatible. You can add new methods and classes and
this implies the ability to innovate. Deprecation can also be used
correctly (not like the JDK) to handle API changes between major versions.
But my impression is that this is no (important) goal for s2, and I can hardly
imagine that it will be one day just because it gets to a point where
_today's_ most wanted features are implemented.
Not yet, but I want to make it one. I think since the plugin system
allows developers access to APIs that were at one point internal, it
changes things quite a bit. These APIs are now public and need to be
stabilized at some point. Otherwise we will end up having developers who
are constantly battling with upgrading plugins and applications and get
turned off by Struts.
But maybe this is worth a new thread...
Agreed ;)
-bp
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
