struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Pontarelli <br...@pontarelli.com>
Subject Re: API Compatibility
Date Thu, 21 Feb 2008 15:14:19 GMT

 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


Mime
View raw message