Right now I’m recreating my strategy on versioning.

My current process was to:

1. Make sure the updated files in my working copy are committed to the SVN repository.
2. Import a temp file using OASIS-SVN Update Process which is configured to kick off a process to update the version number.
3. Run a deployment script which copies my dev version and updates the copy with the live environment settings to prep it for being deployed live.

Why is my version scheme connected to importing text source? Good question, probably never really needed to be. Especially since I’m not actually importing anything of substance usually… Usually I’m importing the version module that gets updated with new constants whenever I do an import.

But what this does allow is for my manually set major and minor version number to have the revision number of my SVN repo added. It’s nice because those numbers are incremental, so it provides me with an internal understanding and also allows customers to see an increasing number.

The new way with a Git repository though, requires a different strategy. Commit numbers are not incremental, they are random hash tags.

With that being the case, I’m thinking the new process will be something like:

1. Make sure the local Git clone changes are committed.
2. Create a Git Tag with a manually created version number. Which will tie a particular commit hash to the version number.
3. As part of the process before creating the tag, I should also update the version numbers in the app itself. So maybe I can automate creating the Git tag from the current working copy.
4. Then after the version number is embedded and the Git tag is created, I can run the deployment script to prepare it to be sent to the customer.

Hmmm… These are just my initial thoughts. I feel like I’m missing something, but I guess time will tell as I try to implement this.