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
