Indeed we work hard to provide either deprecation cycles with APIs that can be used with either. Or else simple ways to do #ifdef logic to make it easier for downstream. But sometimes forking the development is either easier or necessary.
If you do fork it’s recommended to start a new series.
In ROS development the most common way to do this is a minor increment for each forked distro.
For example if you have a version 1.0.0 in indigo new releases into indigo would be 1.0.1, 1.0.2 etc. Then if you do not need to change anything for Jade, you can continue to use the 1.0 series. However if you need to fork your development tree you should start a new numbering series and jump up to 1.1.0 for Jade.
Then if you have to fork again for Kinetic you would move up to the 1.2 series, so start with 1.2.0.
There’s a slightly related discussion in this thread where we discuss the actual number selection. And to follow semantic versioning it might actually make sense to increment the major number not the minor number based on our stability requirements.
But to directly answer your question, you’re correct that the tags are independent of the rosdistro. If the code is the same you can use the same releases. However if the code is different you should use a different release numbering series.
Note that you can always jump upward. So if you initially release the same version into Kinetic on a 1.0.x release to match Jade. But then the head diverges you can up it to 1.1.0 for Kinetic and leave Jade on the 1.0.x. One thing to be aware of is that if you fork something for Kinetic to 1.1 where Indigo and Jade are 1.0, and then you want to fork for Jade, you’ve backed yourself into a corner as you need to pick a different higher number series, and you’ll likely end up with jade on 1.3 while Kinetic is on 1.2. But you could jump Kinetic to 1.4 to keep the relative numbering between Jade and Kinetic. It’s not necessary as it’s only required to be monotonic within a distro, but I recommend working hard to avoid this corner case…