If you take a look at the Jetty[1] or Spring[2], they are doing the
milestone release for the big version release.
I guess there is no big user to use that kind of milestone release in
production, but it tells the user we are moving forward, if you take
some time to try it , you will not spend lots of time to migration when
the final stable release is out.
And the mile stone release can get lots of useful feed back and we can
keep pushing it to the GA release.
If we don't make a trunk as Camel 3.0, we will never get Camel 3.0 out
:)
[1]http://www.eclipse.org/projects/project-plan.php?projectid=rt.jetty
[2]http://static.springsource.org/spring/docs/3.0.x/changelog.txt
On Sat Sep 24 21:48:08 2011, Hadrian Zbarcea wrote:
I don't think we're debating if, we're debating when. I get your point
and I would agree if this was any different than before. The reality
though is that *every* single minor release of Camel was *not* 100%
backwards compatible. We absolutely strive for backward compatibility
and 2.9.0 should not be worse. We should be 100% compatible in patch
releases though.
The reality is that when we'll start working on 3.x we won't have it
for at least 9 months, most likely. Nobody will migrate to a 3.0-Mx
milestone release. It's also likely that many won't migrate to a new
2.x while we actively work on 3.x. In the patch releases we only have
a small subset of the new features on trunk.
I know some are kinda tired of 2.x and want to look at and talk about
the next great thing. We had this discussion a year ago and promises
were made that 3.0 will be out in Q1 2011. We don't yet know how 3.0
will look like, although many have their ideas. We know that we want a
cleaner api, we know we want it leaner and we know that we want
shorter build times and other few things. We can easily continue to
work on that and the other features that come with every release until
we figure out how 3.0 will look like. Doing it now is, imho, a
distraction.
My $0.02,
Hadrian
On 09/24/2011 08:18 AM, Hiram Chirino wrote:
The fact that it's not 100% compatible IS why it's not a good idea to
call it 2.x. The point of version numbering schemes are to reflect
the compatibility between releases. If trunk is not a major release,
I don't know what is. And yes I would hope that the 3.x line tries to
keep as much backward compatible support with 2.x as possible.
Otherwise, you've got a brand new product in your hands and your 2.x
users will have a big wall to climb to to upgrade to the 3.x. As for
dropping deprecated APIs, I'd do that in a 3.1 or once we verify that
migration to 3.x is fully backward compatible from 2.x (I'm sure we
will miss some compatibility stuff in the first few releases of 3.x).
Regards,
Hiram
FuseSource
Web: http://fusesource.com/
On Fri, Sep 23, 2011 at 11:12 AM, Christian Schneider
<ch...@die-schneider.net> wrote:
I just talked to Dan and Hadrian about this idea. The problem is that
however we would call such a release people would take it as kind of a
milestone and it would probably not be used much.
So it is probably better to use the 2.9 and perhaps 2.10 release for
that.
The 2.x naming will suggest that it is mostly compatible and we can
mention
in the release not that it is not 100% compatbile.
For people who do not want the changes we can use the 2.8.x branch.
So we
could keep porting back some improvements like Dan did for people
who want
to stay 100% compatible.
Christian
Am 23.09.2011 16:43, schrieb Christian Schneider:
Basically that is a good idea. I also thought about a similar
solution. I
would only not like to call it milestone as that typically implies
that it
is instable. No sane admin will deploy a milestone release in
production.
How about 3.0.0-compat or similar. So we could have one or more
releases
of this that are fully production ready but will still contain the
@Deprecated classes. Then we can release Camel 3.0.0 that simply
removes
these.
Christian
Am 23.09.2011 15:59, schrieb Willem Jiang:
I think the main concern of Christian is he afraid Camel 3.0 won't
have
much user to use, and he explain us the recent back ports of Camel
2.8.2 is
because of the API change in Camel 2.9-SNAPSHOT.
How about we treat the Camel 2.9 as the Camel 3.0-m1. When we
developed
Camel 2.0, we actual did three mile stone release to fill the gap
of the API
change.
For the user who want to do some release just after Camel 3.0 RC
is out,
he can keep using Camel 3.0 mile stone release.
For the user who just want use the stable Camel 2.x, he can chose
Camel
2.8.x, as we already did a lot of merge of on the Camel 2.8.x branch.
Camel 3.0 Mx can tell the user what API change will be made, and
we can
removed the @Deprecates API when the Camel 3.0 is shaped.
Any thoughts ?
--
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
Talend Application Integration Division http://www.talend.com
--
Willem
----------------------------------
FuseSource
Web: http://www.fusesource.com
Blog: http://willemjiang.blogspot.com (English)
http://jnn.javaeye.com (Chinese)
Twitter: willemjiang
Weibo: willemjiang
