I agree with Mike.
Changing the API and asking the community to migrate is a very high requirement for community members. Personally I think it is too high. I’m motivated by for example, the PR2 community survey (march ’15) where over 70% of the users were 1 or 2 ROS distributions behind. Non-portability of current work was a big motivation in that (52.9%). And this just *between* ROS versions, which is nowhere near to what is being proposed in ROS2.
So at least maintain the existing APIs. Incrementally improve ROS and add new APIs for new features, as you see fit. Swap out custom technologies for tried and tested newer/better/… Much of this is possible without breaking existing stuff, and moreover it can bring improvements to the existing ecosystem ‘for free’.
Have a migration plan with automatized migration tools. (Semi-)automatic source code rewriting is no black magic and it will be a big help e.g. in those cases where an API change is needed. Google does this with Go and it seems to work out well for them (see 'Mechanical source transformation’ in
http://blog.golang.org/go-fmt-your-code).
To repeat myself: big bang releases are very risky and very costly. Gradual improvements like above avoid this risk, and may even allow the community to use new features sooner and/or profit from the improvements in the back-end.