I'm revising my vote to agree with Tetsuo on all three of his aspects. (That semver.org link is an excellent and concise capture of everything I have been trying to advocate, thank you for providing it!)
Regarding semantic versioning, note the paragraph starting with "A simple example will demonstrate how Semantic Versioning can make dependency hell a thing of the past." This is *exactly* what I am talking about with independent module versioning. Version ranges completely avoid a compatibility matrix. Brian On Aug 29, 2011, at 9:28 PM, tetsuo wrote: > non-binding > > -1 to independent module versioning. I don't want to have a compatibility > matrix like Hibernate's ( > http://community.jboss.org/wiki/HibernateCompatibilityMatrix). > > +1 to semantic versioning (http://semver.org/) > > -1 to jump to 6.0, unless it features some major architectural change like, > make Wicket mostly stateless or something like that. Even with that, I'd > prefer to go with 2.0 instead. Large numbers, for me, indicate bloat (with > the exception of Chrome, because we don't even care about the version number > anymore) and instability. If we look to some very stable projects, they are > still in their 2.x or 3.x versions, even with almost, or more than, a decade > of history (Apache HTTPD, Linux, Spring, Apache Commons). Tomcat only is at > version 7 because it increments every time the specs versions change. But > which quality Java framework has such a high version number? > > Tetsuo > > > > On Mon, Aug 29, 2011 at 8:36 PM, Brian Topping <[email protected]> wrote: > >> -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 >>> >> >>
