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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
