Releasing bug fix while new dev version is also in TestFlight

I have a question similar to https://forums.developer.apple.com/message/66397#66397. Here is the scenario.


Suppose I have released version 1.0 of my app. (Numbers aside, this is the case.) I have already started working on 2.0, and have sent beta versions of 2.0 — with that version number and various (monotonically increasing) build numbers — to iTunes Connect for our Internal Testers to test.


Now I have a bug fix for 1.0, call it 1.1. I have the original 1.0 source code, Xcode project, and even the Xcode version it was built with. So I can build an Archive with the bug fix.


But.. I will not be able to send the 1.1 archive to iTunes Connect, because it is a smaller version number than the 2.0 beta versions I have already sent to iTC. It seems my only option is to call the bug fix 2.0.1, but that is ridiculous. Have I really backed myself into a corner with iTC by testing 2.0 betas? Surely there is a way to do multi-branch releases with iTC.

Computers do not understand going backwards numerically. If you meant to release a fix for

1.0, you should never have submitted 2.0.

I did not submit 2.0 to Apple. I just sent it (via iTC and TestFlight) to internal testers. This is how Apple wants us to do beta testing. This is normal development procedure. The problem here is that iTC does not recognize that development takes place on separate branches: release maintenance and future development. You are telling me that once I send a beta of any version newer than the released one, I can no longer update the released one? That sounds pretty limited. Nobody develops that way.

I would submit the 1.0 fix as version 2.1.

Then submit the proposed 2.0 version as 2.2.

Not ideal but it still gets the job done.

Releasing bug fix while new dev version is also in TestFlight
 
 
Q