Not really sure to which of the many messages to reply to, I just chose
this one. I tried to educate myself on what the issues are (obviously
more than one). Thanks to all who helped, you know who you are.
I understand that we all agree on the need to maintain backward
compatibility close to 100% on minor releases and even in 3.0 as much as
possible, and give a clear, simple migration path when not possible.
Some of the changes for 2.9.0 did break compatibility, but with they
were resolved in most part due to Claus' comments and his work with
Christian.
If I understand the statement below correctly, as of now the trunk is in
an acceptable state and could continue as 2.9-SNAPSHOT. As long as other
incompatible changes won't be introduced we are in an ok shape as far as
backward compatibility goes. It would be a good idea to start closing
down for a 2.9.0 release as well, use the remaining time to stabilize
the trunk and fix remaining issues and possibly issue an early RC
release for 2.9.0.
We should also restart the discussions about what we want in camel-3.0,
there are already a good number of ideas floating around, and as soon as
we have a critical mass of agreement on 3.0 improvements move the trunk
to become 3.0-SNAPSHOT. If we need more experiments for 3.0 it is
preferred to do them on branches or in a sandbox.
Does this sound acceptable?
Hadrian
With the current state of trunk as Camel 2.9.0, then I actually share
a view to release early to give the community a chance to give it a
spin.
Also because Camel 2.9.0 is *not* going to be like any other regular
minor releases we usually do.
So doing 1-2 RC releases could be a good thing for the community.
