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
