exactly my point.
On 3/8/07, Jonathan Locke <[EMAIL PROTECTED]> wrote:
this feels too aggressive to me if 1.3 is to be released through
apache. we
want our first apache release to be the best it can be, not as fast as it
can be because we've been promising it for a while. let's give ourselves
a
break and take the extra days it takes to backport model changes and
important features to 1.3. if it takes even another month, it's still
better because our story of what to use is more understandable... 1.4should
really just be 1.3 + generics changes. that's very simple to explain.
btw, let's not kick ourselves for working on 2.0 for a long time and
falling
behind our earlier promises of scheduling. unpredictable things have
happened and these kinds of things happen even on the best projects. to
our
great credit, we've shown a willingness to evaluate our own work, suck it
up
and kill our darlings, as someone said. that's what makes something
great.
let's not push out a 1.3 that's less than it should be to meet a schedule
we
simply couldn't meet due to unforseen circumstances. i vote to slow down
in
spite of any scheduling pressure we may be feeling.
jon
igor.vaynberg wrote:
>
> pasted from almaw's email on @user
>
> -igor
>
> -------------------------- 8><
> --------------------------------------------
>
> In my opinion we could, within the next:
> -----------------------------------------
> 1 week - Push 1.3-betas as-is.
> 2/3 weeks - Bug fix as people test it and push out rc's when
> we feel it's solid and stable.
> 4 weeks - Rename 1.x branch to 1.3.x.
> - Release 1.3.0 final and put 1.3.x immediately into
> maintenance mode.
> - Create 1.4.x branch from 1.3.0 tag.
> - Merge the model changes from trunk to 1.4.x.
> - Backport anything else from trunk to 1.4.x that's
> not JDK5-specific.
> 6 weeks - Push out 1.4-betas
> 7/8 weeks - Push out 1.4-rc's
> 9 weeks - Push out 1.4.0 final
> - Create 1.5.x branch from 1.4.0 tag.
> - Backport/add generics, covariance and other JDK 5 trunk
> features to the 1.5.x branch.
> - Move trunk to "2.0_deprecated_-_use_1.5.x_instead"
> 14+ weeks - Release 1.5.0
>
> Suggestions to make this work:
> ------------------------------
> We won't backport from 1.4.x -> 1.3.x.
> We won't actively develop trunk.
> We will push 1.4 out very soon after 1.3, and encourage migration.
> We will have this in a public roadmap so people can see it coming.
>
> Notes on what you think is insanity, but actually isn't:
> --------------------------------------------------------
> We will of course end up with five(!) branches (1.2.x, 1.3.x, 1.4.x,
> 1.5.x and what's currently trunk). This may seem like madness to you,
> but I reckon it isn't:
>
> During 1.3 development, 2.x is low activity, 1.2.x negligible.
> During 1.4 development, 1.3.x and 2.x are low, 1.2.x negligible.
> During 1.5 development, only 1.4.x will also be quite active.
>
> Once 1.5.0 is out, we can properly deprecate 2.0. People currently using
> it may not like being told to migrate to 1.5.x, but that shouldn't be
> too hard (much less hard than going from 1.3->2.0) and there shouldn't
> be too many of them. I guess that's the price you sometimes pay for
> using unreleased software. :-/
>
> I'd envisage 1.4.x will require some backports from 1.5.x. We'd
> obviously encourage core developers and patchers to upgrade their sites
> to use 1.5.x, do active development on that, and therefore try to only
> ever backport from 1.5.x to 1.4.x, not forward-port the other way
around.
>
> If you think I'm smoking crack, the above is utterly unreasonable, you
> want to kick me out of the gang, or you have any better ideas or
> suggestions as to how to keep everyone happy, please shout now. :-)
>
> Best regards,
>
> Alastair
>
>
--
View this message in context:
http://www.nabble.com/roadmap-tf3366743.html#a9372002
Sent from the Wicket - Dev mailing list archive at Nabble.com.
