Re: [Springframework-developer] Release policy

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

1.0.x sure does mainly imply a bugfix release: I just intend to allow =
*minor* (really minor) features to slip into such point releases if =
they're ready. I'd like to release early here, instead of waiting for =
the next 1.x release. For examples, take Hibernate 2.0.3 (which =
introduced "all-delete-orphans") or Tomcat 4.0.4 (which introduced the =
Coyote HTTP connector).
=20
My main argument is about the 1.x releases though. I'd like to have a =
quick 1.1, possibly with JMX support and JMS support; then a 1.2 with =
whatever gets ready next - instead of waiting for all those major new =
features to be ready for a single combined release. I simply feel there =
are too many major features planned when I look at our JIRA roadmap for =
1.1.
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von Mike Cannon-Brookes
Gesendet: Do 04.03.2004 14:57
An: Spring
Betreff: Re: [Springframework-developer] Release policy



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,
>
> 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.
>
> 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.
>
> 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.
>
> 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)
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> In other words, let's adopt a Hibernate-style release policy, not a
> Jakarta-style one ;-) Eagerly awaiting your feedback!
>
> Regards,
> Juergen
>
>
>
> -------------------------------------------------------
> 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



-------------------------------------------------------
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=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer