struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Don Brown" <mr...@twdata.org>
Subject Re: API Compatibility
Date Thu, 21 Feb 2008 20:56:27 GMT
But don't you see, if we used the more traditional 1.0-alpha-1 ->
1.0-beta-1 -> 1.0-rc-1 -> 1.0 then we could produce releases that
drastically changed the API within a single version.  As it is now,
there could very well be huge changes from 1.0 to 1.0.1 because every
release gets its own numeric version number, regardless of quality.

I agree the changes in 2.1 are very significant, so much so that they
necessitate multiple alpha releases to get feedback from the
community.  Currently, there is no way to do that without releasing
2.1.0 -> 2.1.1 -> 2.1.2.

Again, the versioning discussion has happened many times before, and
individual numeric releases is how the community has decided to run
Struts, and that's fine.  Then, the question becomes how we can better
educate our users on what to expect.

Don

On 2/22/08, Brian Pontarelli <brian@pontarelli.com> wrote:
>
>   From my perspective the issue isn't education, it is compatibility at
>  the code level. Making changes that severely break plugins and
>  applications needs to be reserved for major releases. Here are two
>  examples that had severe impacts:
>
>  - Making XWork objects immutable with the builder pattern
>
>     This change broke a number of plugins because that API is public and
>  reducing visibility or removing methods is not a compatible change.
>
>  - Changing the names of the interceptors in struts.xml
>
>     This change broke all applications that had custom interceptor
>  chains. This is a higher level of public API in the configuration files
>  and renaming methods or ids is not a compatible change.
>
>
>  These types of changes seem to be the largest issue with the versioning
>  of Struts 2.
>
>
>  -bp
>
>
>
>
>  Don Brown wrote:
>  > Yeah, the way Struts does versions kinda breaks this.  You could see
>  > very major changes between 2.1.0 and 2.1.1 because neither made GA.
>  > Once a GA release has been made in a series, however, the normal rules
>  > apply.  It is beating a dead horse to say I never liked the Struts
>  > versioning system, so moving forward, how can we better educate our
>  > users on how things work?
>  >
>  > Don
>  >
>  > On 2/21/08, Brian Pontarelli <brian@pontarelli.com> wrote:
>  >
>  >>  >> 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: dev-unsubscribe@struts.apache.org
>  >>  For additional commands, e-mail: dev-help@struts.apache.org
>  >>
>  >>
>  >>
>  >
>  > ---------------------------------------------------------------------
>  > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>  > For additional commands, e-mail: dev-help@struts.apache.org
>  >
>  >
>
>
>  ---------------------------------------------------------------------
>  To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>  For additional commands, e-mail: dev-help@struts.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org


Mime
View raw message