Some of these have not been updated for the new catkin style packages/metapackages, but there is the Stack Version Policy on the wiki. There are couple of guidelines here that are pretty prevalent in ROS:
- After 0.4.0, the API should generally try to be stable (although, understandably it may not).
- After reaching a 1.0 level stacks released into distros are expected to be stable within a release
Additionally, for 1.0 and above, REP9 discusses ABI compatibility within a release. Unfortunately, this part is not well followed.
This brings us to "within a release" -- once the beta has been announced, you should not break the API for >1.0, and hopefully not for >0.4.0 releases, it should really only be bugfixes from beta time to "release". Hopefully, you also avoid breaking the ABI, but this is rarely caught anyways, since the buildfarm currently rebuilds all downstream projects when you release.
None of this is really enforced by some sort of build farm test or rosdistro test or whatnot that tells you "no, don't release this into X, release into distro X+1", you as a developer have to be diligent with what you release -- if not, it can cause major headaches downstream. For instance, long after the beta ended, Groovy RVIZ changed how it dealt with DAE file scaling, which meant that a number of robot packages became broken as they had been hacked to work with the older, not quite proper, scaling. Yes, it made sense to fix this, but should not have been released into Groovy. Due to the staging involved in getting a new set of freshly built packages out the door, this meant that for about 2+ weeks, anyone installing TurtleBot from fresh packages had a completely broken visualization. We've also recently had issues when packages were catkinized mid-way through the life cycle of a distribution.
TLDR: don't change things without thinking, there isn't a lot of infrastructure to tell you when you are about to break the world.
New packages should be OK, since presumably nothing else depends on them yet.