Dan North wrote:
So, here's my thinking.
Runtime frameworks (xstream, sitemesh, objenesis, ...)* are governed by
what operations people are prepared to support in a production
environment. This usually means they are several JRE versions behind,
because ops people are notoriously conservative about upgrading things.
Development frameworks (jmock, hamcrest, ...)* can be more adventurous
because they don't have an impact on the production environment, just
the developer setup. JBehave falls into this latter category, so I'm
less worried about having it depend on Java 5.
We could do this in stages as Mauro suggests, by having some extensions
that use (and require) java 5 and others - and the core - that are still
1.4 compliant. Or we can bite the bullet - given that jbehave currently
has a relatively small user base (I'm assuming here, based on the list
traffic) - and move to 1.5. This would give us an opportunity to review
the codebase and see where generics and annotations might help make
jbehave more expressive.
Plus we get hamcrest for free.
What do you guys think? (Subject of course to consulting with that user
base :)
Thoughts in no particular order:
In general, I believe that a good rule of thumb is supporting 1-2 JDK versions
from the current.
So the case for JDK 1.4 support could still be made. But given that:
- 1.5 gives us so much more "language" features (as opposed to a library
bundled in the JDK)
- we have several new libraries/frameworks that require 1.5
- jBehave is not a production library - but a testing one
I would be inclined to move to 1.5.
To support 1.4 users, we could keep 1.x branch on 1.4 compatibility, and create new 2.x branch for
1.5 (as jMock, Pico and other projects have done).
Cheers
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
