I am a pretty lazy guy and therefore I want to do all things with as little trouble as possible. Usually , I don’t plan a certain methodology for my projects, instead , I use an organic approach. If things are needed, they will be added to my ‘methodology’.

One of the most important issues for me is versioning . It doesn’t matter whether you are using svn , git , or whatever, it’s only important to be able to version via tags ( I use tags) or other mechanisms .

When you work from time to time on a particular project, you will certainly loose track of what you do and you will probably forget most of your code.   For me it’s important to know the differences between versions, even if I don’t plan them.

The standard versioning system is composed of 3 digits : like x.y.z . Most of the people think these numbers are random , or incremental , but they are not. For example if product A has the version 1.1.0 and the next version is 1.1.1 , i will know that some bugs have been fixed.  A changelog will  further detail this . If the next version will be 1.2.0 I know that some new features will be added to the product. If the new version will be 2.0 I know product A will go trough major changes and most of the base code will be rewritten and improved (also means backwards compatibility is broken).  And finally , if product A is versioned 0.y.z , I will know that the product is not considered ready yet.

How do I use this in my projects?

If I work on small things , bug related stuff, I will increase the minor ( z) . So from 0.1.0 I will go to 0.1.2 .

If I add new features, I will increase the middle digit (y). So from 0.1.0 I will go to 0.2.0 .

If I finish a first stable and complete version, I will go from 0.1.0 to 1.0.0 .

At deploy

Let’s say my current version is 0.1.2 and  the new version is 0.2.0 . My site being www.example.com , I find it convenient to create the following subdomains : sandbox and history.

First , I will place the new version ,  0.2.0 in the sandbox environment. All the testing will be done there. If everything looks ok,  example.com  contents  will move to history, and sandbox will move to the live site, example. com

So at this point, the environments will be as follow:

example.com - 0.2.0
sandbox.example.com - 0.2.0
history.example.com  -  0.1.2

If anything goes wrong , I will easily revert example.com to 0.1.2 , using the history environment.

Having versioning in place , allows you to see all the changes that took place in time , and also provide snapshot of your application from the past.  If you provide meaningful description to your commits, you will be able to generate a nice automated text that will build your changelog.

Hope this helps.