+1 -igor
On Mon, Aug 29, 2011 at 3:15 PM, Martijn Dashorst <[email protected]> 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 >
