[Springframework-developer] Release policy

[<jue...@we...>]

Everybody,
=20
I'd like to propose a somewhat different release policy for post-1.0. =
Currently, we're targetting a major 1.1 release, with a M1 milestone as =
first goal. This doesn't seem very appropriate for getting features and =
add-ons out early.
=20
When I look at the 1.1 roadmap in JIRA, almost all suggested features =
are add-ons that do not affect the Spring core. They could easily be =
added one-by-one as soon as they're stable. 1.0 users could still easily =
upgrade without worrying: Such 1.x releases would be fully compatible, =
mainly adding additional classes.
=20
OGNL support probably requires special consideration: However, if we =
added it via a FactoryBean implementation analogous to =
MethodInvokingFactoryBean, it would be a simple add-on too.
=20
So what I'd like to propose concretely is:
- quick 1.x releases, getting out smaller sets of new features and =
add-ons early
- no milestones for 1.x releases, just release candidates
- CVS HEAD always contains the current 1.x codebase
- bugfix releases like 1.0.x only when there's no compatible next =
release like 1.1 available
- 1.0.x/1.1.x/etc releases can also introduce minor new features if =
appropriate
- major new features or add-ons force a jump to the next 1.x release =
number (1.0 -> 1.1)
=20
This essentially means that we do not stick to a release plan that's =
cast in stone. Assuming that 1.0 final will be out in mid March, we'll =
simply work on some planned features: in the sandbox while not fully =
baked, moving to the main source tree when something approaches release =
candidate status. Once a noteworthy number of new features is there, =
we'll do a follow-up release: in case of bugfixes and minor features, =
1.0.1/1.0.2/etc; in case of one or more major features, 1.1/1.2/etc.
=20
My main intent is to get new features - that are ready and do not =
require signficant modifications to the Spring core - out promptly: When =
we finish FreemarkerView, let's do 1.0.1; when we finish JMS support or =
any such major feature (one or more), let's do 1.1. When e.g. JMX =
support gets done, we'll do a follow-up 1.2; or the other way round, if =
JMX support gets ready first. If there's pressure for a bugfix release, =
let's fit that in; it might also contain minor new features that are =
ready.
=20
If we decide to break compatibility (beyond trivial things in rather =
obscure places) at some time, we need to jump to the next major version, =
doing further bugfixing for 1.x and such new development on a 2.0 branch =
in parallel - then and only then. I see no need to impose such burdens =
for add-on features in 1.x releases, particularly when raising them in =
the sandbox before they join the mainstream.
=20
All things considered, the release policy that I propose is much more =
agile than a fixed set of 1.1 features that will just make it into a =
final release when all of them are ready. A large number of such fixed =
features could delay a release for a long time. Note that significant =
changes to the Spring core are a different matter; features that depend =
on such require special consideration. But for rather straightforward =
add-ons, we don't need to tie ourselves to a strict release plan, IMO.
=20
In other words, let's adopt a Hibernate-style release policy, not a =
Jakarta-style one ;-) Eagerly awaiting your feedback!
=20
Regards,
Juergen
=20