Training on Versioning - Tortoise, and Request Pulls on Redmine [★]

December 10, 2012

Last month, our office held a training for its Team Leaders and Junior Programmers about the right method of tagging versions in the mercurial repository of projects. This knowledge is extremely useful especially in tracking changes for bug fixes in the code repository. Since each project is handled by a team of programmers, correct versioning can come in handy when reverting changes and controlling fixes to be included in the next deployment patch. It is important for each member of a programming team to learn even the basics so that handling of changes in the program codes in the future would be accurate and easy to manage.


Every programmer knows this by heart, but in case you need a little refreshing of the memory, here are the stages that a project goes through before live implementation:

Data Gathering 
QA Testing

1. Data Gathering
This is the stage where the Function Specifications Document (FSD) is drafted. The FSD contains all the functionalities that the system is expected to do upon completion of the project. This is signed and agreed by both parties (the developers and the clients).

2. Development
This is when the programmers are all in action. Different modules are being programmed in this phase by the developers in the team project. They do unit testing to ensure that all that they have programmed are working properly as expected, and that bugs, caused by common programming mistakes, are already eliminated.

3. QA Testing
After everything has been coded by the programmers, the team leader (or gatekeeper) of the project team consolidates all the bug revisions of each of the programmers. The system, with all the changes included, is then deployed in an environment which then goes under a thorough testing by QAs to assure that the system is bug-free. They test all possible scenarios for the system, even the invalid ones (especially the invalid ones!) to ensure that the system handles all errors and implements all validations correctly, and that the system still behaves normally despite invalid inputs by the user.

4. Users Acceptance Testing (UAT)
It's the turn of the clients to test the system! During this phase, the clients do a hands-on testing on the system and submit bug reports for error that they will encounter to the developers. The developers then fix these issues. They are then tested again by the QAs before it is deployed in the UAT environment again. The clients then retest the same scenario again and check if the error does not occur again. If the clients are satisfied with the fix, they finally close the issue.

5. Production and Support
This is the stage where programmers can do a little celebration because the system will finally go live! However, bugs can still appear during this stage, which should be fixed as soon as possible by the developers.

The benefits of repository versioning is most useful in the UAT and Production stage because it can be used to ensure that only specific fixes will be included in the version of the project code to avoid repercussions and retesting of other modules.


Notice that in software releases, there are numbers appended at the end of each of the version name. One example is the Android releases:

Android 1.0
Android 1.1
Android 1.5 (Cupcake)
Android 1.6 (Donut)
Android 2.0/2.1 (Eclair)
Android 2.2.x (Froyo)
Android 2.3.x (Gingerbread)
Android 3.x (Honeycomb)
Android 4.0.x (Ice Cream Sandwich)
Android 4.1/4.2 (Jelly Bean)
The common code versioning format is 


which means 

x = major version (start of a project)
y = minor version
z = fix version
e = emergency patch


Given the implications of the versioning, there are practices that should be implemented when coding and committing issues in Redmine (at least for our office):

  • Commit your changes for every bug that you fix.
    • refs #<Redmine Number> : <description>
  • Queue it to the correct version. Indicate the Cause and Resolution for the issue.
Above are the practices for the developers. There are separate tasks for the Gate Keepers, Team Leaders, and QA Testers (though I will not include it here anymore).

There are also steps that should be followed when merging nodes and fixes in Mercurial to ensure that only the selected fixes would be included in the resulting repository copy.


There was also a hands-on exercise during the training, but I cannot remember most of it now. ><
I would take note of them starting from today and publish it here in my blog for future reference, and as aid also for other people/programmers who might be needing the information. :)

  • Share:

You Might Also Like

0 (mga) komento

I would love to hear your thoughts! ✨