If I met all requirements on version 1.0 and go on working towards version 2.0, new features would be 1.1, 1.2, 1.3, and so on. What do I version the commits that represent an important fix or a forgotten feature which is required in version 1.0? Even if I didn’t version fixes on version 1.0, there would still be two version 1.0.1s until the develop branch merges into the master branch.
If you continue to develop on 1.0 then 2.0 should be a fork. Making changes in 1.0 after the fork will fragment you no matter what you do.
Python ran into this problem and to this day Python 2 and Python 3 are looked at as different languages.
If you don’t want to fragment forget 1.1 and put everything in 2.0. It doesn’t even matter if 2.0 isn’t published yet. If you create a situation where you’re making bug fixes in two places you are fragmented.
It’s not that you can’t fragment. It’s that the costs of fragmenting will sneak up on you. Modern version control systems can help mitigate some of this but even just the costs to testing make fragmenting a hard to justify situation.
2
Assuming version 1.0 is released then the question is whether you plan to release the fixes, forgotten features etc. If so, it has to be a new version say 1.0.1 or 1.1
Otherwise you can incorporate all these in the next version to release. As others said you should not send out different bundles of the same version.
In any case, I think you should develop a mindset, policies and practice to work on new versions. This will keep your code well organised in a version control system. Check the material for semantic versioning. It provides a good approach to many questions like this
It sounds like you already have a practice of “releasing” a version by merging develop down to master with a new tag. That is as granular as you need to get. You might have several changes that get posted and merged to develop during your release cycle, but each one doesn’t necessarily require a version increase; the version should go up only at the next merge down to master, and the version’s change set would be the aggregate of the tickets that came down in between the last merge from develop to the current one.