Re: [Springframework-developer] Release policy

[Mike Cannon-B. <mi...@at...>]

Love it - great ideas.

I don't really think the versioning number matters really, although 1.0.1
sounds more like a bugfix release to me than new features?

Cheers,
Mike

On 4/3/04 8:13 PM, "j=FCrgen h=F6ller [werk3AT]" (jue...@we...)
penned the words:

> 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 f=
irst
> 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 upgrad=
e
> without worrying: Such 1.x releases would be fully compatible, mainly add=
ing
> additional classes.
>=20
> OGNL support probably requires special consideration: However, if we adde=
d 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-on=
s
> 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 numb=
er
> (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 wor=
k on
> some planned features: in the sandbox while not fully baked, moving to th=
e
> 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 m=
ore
> 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 finis=
h
> FreemarkerView, let's do 1.0.1; when we finish JMS support or any such ma=
jor
> 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 obsc=
ure
> places) at some time, we need to jump to the next major version, doing fu=
rther
> 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 i=
n 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 agi=
le
> than a fixed set of 1.1 features that will just make it into a final rele=
ase
> when all of them are ready. A large number of such fixed features could d=
elay
> a release for a long time. Note that significant changes to the Spring co=
re
> are a different matter; features that depend on such require special
> consideration. But for rather straightforward add-ons, we don't need to t=
ie
> 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
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id638&op=CCk
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer