Most of our users won't know our deprecation policy further than these annotations so doing more seems pointless.
I agree that annotations are likely the primary communication channel for deprecations. I don't think the intention of the proposal is to change that, just to make some notes about what we as a development community think is a good balance between giving users reasonable predictability in terms of preparing for breaking changes, and us enough flexibility to fix broken stuff.
It's been insightful for me to see two quite different opinions on what we should be aiming for. I wonder whether we can get some data on how/if our current rate of change is causing problems for customers, to help guide this further?
jclouds can go this way but we should expect that every branch from master will increment the major version and just define minor releases away.
I guess that's the idea, yes. But in any case I don't think we need to decide anything on that front until 2.0. Whether we say "the next major version is 3.0", or whether we call it 2.0.0 and say "the next major version is 2.1", seems like a bridge we can cross when we get to it ;-)
ap
