Menu
▾
▴
springframework-developer
|
From: <jue...@we...> - 2004-03-04 09:26:12
|
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 |
|
From: Mike Cannon-B. <mi...@at...> - 2004-03-04 14:11:19
|
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 |
