The way I do this stuff myself is to keep plenty of different rom files on my pc naming them with version number starting from 0.01 like you have. Current version has version number something close to 10.00 :D, so 1000th version practically.
Anyway, I plan out beforehand, what I'm going to include in the version I'm going to release in public next and make sure I just got all that stuff done for it (along with testing that everything should work out properly in the game after I'm done. At this phase, something will change because there ought to be a bug or two around which I haven't noticed, or have carelessly "put up" by re-changing a functionality or two which I had already implemented before and knew that that functionality worked back then). Once I'm done testing and bug fixing the game, I may even make another test run since I put up new releases very rarely. Once I'm done with another test run, I release that version I've got (let's say, v. 3.74) by name Beta 2, 3 or so on.
And if I want to update that version with some new changes without changing the length of the gameplay that much, I may put up a new version by name Beta 2.1, 3.1 or so on (which could match to v. 3.92 for instance).
What comes to version control as well, I've got a Github account, and in Github, I have put up a repository of all the necessary files I have in my pc. The file system I have is like this: /Dark Energy (newest rom files), /Dark Energy/Documents (all kinds of documents and tutorials I need. In case some stuff would be lost in hacking forums, I've still got it around), /Dark Energy/Edits (all kinds of files including information to what kind of stuff I have edited in the game that I wish to have information of. These for example include edits to some asm routines and where they are stored, trainers used in the game so I know straight which ones I haven't used for each Trainer Group, flags of all accessable in-game events (especially handy to have around at least in my case since I do all from scratch and don't use the events of original GS), and used wild pokemon entries for Johto, Kanto and water areas and so on...). Along with these, I've got backups folder where I store all, or most of the backups. I've still got very early version lying around but delete some in between because I'm not going to need all of them. The reason for keeping very early files is to make it simple to get rid of bugs that you notice in your current version that have existed way before already but just didn't notice it then until now. Bug fixing can be achieved with "forking method" by seeking, which version (for example 5.01) is the last one that doesn't have the bug and which version is the first one that has the bug (for example 5.02 in case I have kept backup lying around). Then I can make a patch file using unmodified file as 5.01 and modified as 5.02 and check what the patch file does. The smaller the size of the patch file, the easier it is to discover what causes the bug in version 5.02 and the same cause applies also for the current version you have (for example in this case, 5.41).
Guess I explained way more than just replied to your message, but that happened - hahha :D Hopefully you'll find use of me writing more than I was meaning to at first. But the thing I was talking about Github there is that all this data is stored there as well. So in case my pc broke down, I would have backup of all the data in Github and I could just buy a new pc and download it from there. And Github is a software for version managing. You probably didn't mean to ask for advice with this kind of "version managing", but this came straight into my mind when I saw that word.