Yes, which is why I said 'Installable Units with a major version increment'. But if someone defined a requirement on your features and allowed for minor version updates -- org.eclipse.cdt.debug.standalone.feature.group [1.0.0, 2.0.0), it would fail to install with SR2 because 8.6 does not fall in that version range.
But there are a few bundles that shipped major version increments between SR0 and SR2 too:
org.eclipse.photran.ui (8.0.0.201406102021 -> 9.0.0.201502031411)
org.eclipse.photran.cdtinterface.vpg( 8.0.0.201406102021 -> 9.0.0.201502031411)
org.eclipse.photran.core.vpg.preprocessor.c (8.0.0.201406102021 -> 9.0.0.201502031411)
org.eclipse.photran.ui.vpg (8.0.0.201406102021 -> 9.0.0.201502031411)
a few more photran ones
org.eclipse.persistence.asm (3.3.1.v201302191223 -> 5.0.1.v201405080102)
So going back to my question, what is the current policy on shipping new versions with the Fall and Winter releases? I can't seem to find it explicitly stated [1,2]
There is a bit of information in [3]. But depending on how you read that, either you can do what you want as long as you have a plan, or conversely you should maintain full compatibility, which would mean that changing your feature versions dramatically is a non-starter (this could break workspace setup).
The reason I'm hammering on this point is because until we know what we are doing, it will be hard to define where we want to go. Between the discussions here, on the call, and on twitter, it seems that 6 different people will have 6 different opinions on what we are currently doing. I'm trying to gather some data on our current process so we can define how our current releases are structured (as opposed to how we think they are structured).
Cheers,
Ian