Here is my suggestion:
In the standard branch plan, on the release side, you have two branches per release (for example v1.3 or vCurrent).
Both of these branches are created at the same time (Main ->Servicing; Servicing-> Release). This structure allows for post-release engineering of *unplanned* fixes. These fixes would be made (checked-in) to the Servicing branch, tested and released
from this branch. Since they are minor fixes and emergency hot fixes, it is not necessary to make a read-only copy of every emergency release done here. The Release branch would be made read-only immediately after it is created. There would be no merging from
Main to any release branches or servicing branches. Hot fixes, on the other hand, would be merged back to main (Reverse Integration) so they could be picked up by vNext development.
Rather than look at v1.4 as a release effort, I would prefer to characterize this as a development branch. This means you would have two development branches, vNext (1.4) ande vNext +1 (1,.5). These two development branches would be siblings. It is a minor
distinction perhaps, but I think it more clearly depicts what is going on. Unplanned bug fixes to released code would be checked into a servicing branch for the appropriate release. Planned maintenance work would be checked into a development branch (vNext).
Future development would be checked-into a different development branch (vNext +1`).
This approach allows you to maintain stable branches in Main and Release. I think the workflow you describe is not impacted by this semantic change for the Release 1.4 branch. It continues to be read/write with CI. It will periodically merge back to Main
so the vNext +1 branch can pick up these changes from Main.
Until they release, 1.4 and 1.5 should be considered development branches. When ready to release, do a final merge of v1.4 development to Main (after merging Main to v1.4 and testing the integration in the v1.4 development branch). Do a final QA stabilization
of v1.4 in Main and then make the two relase branches (servicing and release). Make the release branch read only.
Later when v1.5 is ready to release follow the same process as for v1.4.
I hope this helps.
VS ALM Ranger