-1 I propose that Wicket modules be released separately. Projects that are small can be released as a monolithic whole. Wicket is no longer a small project. With the changes that went into 1.5 to make it easier to program, there should be very few changes in the core modules.
Maven provides very robust facilities for version ranges that can make sure modules avoid incompatibilities. The rules of when to update these version ranges is very easy to follow. I would be very surprised if anyone was incapable of doing it well. Basically, version ranges of dependencies are kept "open" until there is an API change that requires it to be closed at some milestone. At the end of the day, it doesn't matter really matter how versions are named, what matters is that users expectations are met. I've already referenced Wikipedia entries that cover pretty commonly held expectations that people have, what is proposed here is not far from them. Again, whatever scheme is chosen just needs to be documented and adhered to. Brian p.s. I am presuming I am one of the "anal retentive folks with versioning OCD". Congrats on keeping it classy! On Aug 29, 2011, at 6:15 PM, Martijn Dashorst wrote: > I think I can speak for everyone here that our current release has > taken a long time to stabilize, and finalize (and we are not even > there yet!). Given that we are all volunteers and many of us also try > to have a family and/or social life, it is what it is. > > When we hit RC status, we should be able to pull out a final release > within weeks, not months. The issue is that none of our users will > actually test prior to us releasing a RC. I think that 1.5 matured > considerably during RC phase, especially since several folks dove in > and started shipping products with it (for better and for worse). It > is a testament to the quality of the software built mostly by Igor, > Juergen, Matej and Martin that our systems haven't had any major issue > with Wicket 1.5 in production use (nothing that couldn't be patched > locally). Kudos to you guys for all the effort and countless hours you > put in! > > One thing that anal retentive folks are concerned about is that > breaking API should only be done in major X releases. I've read > statements of folks claiming we are not enterprise ready because we > name our major versions X.Y and even break API in X.Y.Z. While I never > understood the folks with versioning OCD, we can and probably should > improve our versioning strategy even though it currently works for us, > and has worked for us in the last 7 years. > > So I propose that we call our next major Wicket version: Wicket 6, and > the major version after that Wicket 7, and the next major version > Wicket 8, etc. New features that don't break API should go into a X.Y > release. Bug fixes that don't break API should go into a X.Y.Z > release. > > I propose that we develop breaking API features on trunk until we have > implemented our proposed and scheduled roadmap features, while > continuing to support the previous major release. When we have > finalized our roadmap for the next major release, we create a branch > for it: > > branches/wicket-X.x (substitute capital X with the major version number) > > From that point on we can continue developing API breaking features on > trunk for X+1, and start bug fixing on Wicket-X.x branch. This will be > a release train that starts with Wicket-X.0.0, and continues until we > deem Wicket-X.0.z stable for general consumption. The Wicket-X.0.z > release will then be a "GA" release. This seems to be how Tomcat works > and other frameworks as well. As long as we don't bless the release > with "GA" I suggest we add a classifier "beta" to the release. This > results in apache-wicket-X.Y.Z-beta.jar, and > apache-wicket-X.Y.Z+1-beta.jar. When our GA release comes I suggest > just dropping the beta-classifier. > > If needed we can create feature releases that only add new stuff > without breaking old code in a Wicket-X.y release train. I suggest > making such a train when Wicket-X.0.0 or Wicket-X.0.1 has been > released. I would recommend that we EOL support for the previous Y-1 > release as soon as we release a X.Y.0 version. Upgrading would be > easy, and painless. Bug fixes reported against X.Y-1 will be fixed > only in X.Y.z > > As far as schedules: I hope to move to two major releases per year: of > the X variant, and two additional releases of the Y variant: so one > year should have: X.0 and X.1, and X+1.0 and X+1.1. This also means a > roughly schedule of 6 months for a new major X release. > > Doing this kind of releases on such a schedule takes effort, > discipline and community support. I am willing to step in as a release > manager and perform the wicket next releases and keep an eye out for > JIRA issues and scheduling them to the correct versions. > > In my opinion we should number our next Wicket release a major release > and call it: Wicket 6. Rationale: we are going to break API again > (hence a major release), releasing Wicket 2 would be problematic with > search engines discovering old wicket 2 threads and such, I would > +1000 a move to Java 6 as our minimum requirement and -1 staying at > Java 5, and there's precedent of going from a 1.5 release train to big > number 6. > > I'll launch a separate roadmap discussion for what should and > shouldn't go into Wicket 6, so please no discussions of whether a Java > 6 base requirement is warranted or not. That is for a new thread > titled "Roadmap for Wicket 6" posted to the dev@ list. > > Martijn >
