Wednesday, May 1, 2013

Version Numbers, Part 2, Part 1.

Last night we released the first version of Flex with a fourth decimal place in the version number: 4.6.13.2.

Believe it or not, the different decimal places in version numbers do have meaning and our new numbering scheme reflects some underlying changes in how we manage source code and version numbers at Flex.

First off, we recently changed our source control system from Subversion to Git.  As part of this conversion, we restructured our projects and modules to make it easier to branch and merge source code.

Source Control

Under our new regime, we have three main branches of code we work on simultaneously: master, dev-minor and dev-major.  Master is the Git equivalent of Subversion's trunk and for us represents the maintenance or emergency branch.  Most new work happens in other branches, leaving master relatively pristine and unchanged since the last release.  If we're in the middle of coding a big new version of Flex and a severe bug suddenly crops up, we can fix the bug in the master branch and push a release without pushing all the risky new work we're doing along with it.  This allows us to respond to emergencies and push small changes much faster.

Most of the work happens in a branch called dev-minor.  We now do the majority of regular work in this branch and only when we're ready to build a release candidate does the new work get merged over to the master branch for regression testing and release.

Work we consider to be risky or potentially time consuming is done in yet another branch called dev-major.  For example, if we have to rip out parts of the availability engine and rebuild it for performance - a task with the potential to run awry and delay the schedule - we do this in the dev-major branch where it can't delay the work going on in dev-minor.

A Version For Every Branch

The code in each branch has a different version number.  The three digit version numbers we're all used to (e.g. 4.6.14) come out of dev-minor.  Once a routine version has been released, if we find we have to push an emergency or maintenance release out of master, that version has an extra digit tacked on the end like this: 4.6.13.2.  That number tells you that this version was the second emergency release after 4.6.13.

The dev-major branch will get a version like 4.7.0 or even 5.0.0, but it's possible that work done in the dev-major branch could get merged into the dev-minor branch without the version number going with it.  In fact, this happened with version 4.6.14 of Flex.  A number of experimental performance enhancements were done in dev-major and once they were complete and stabilized these changes were merged into the dev-minor branch for the next standard release.

The Point

This may seem confusing to those unfamiliar with source code version controls systems, but the point of all this complexity is to make is easier for us to get our work out sooner.  The schedule is no longer at the mercy of the most complex task on the schedule.  We can isolate the time consuming or risky things in their own branch and get other functionality out faster.  We can also respond faster to emergencies or minor maintenance issues.


This process is already starting to work.  Version 4.6.13.2 went out last night, but version 4.6.14 is almost ready and work on version 4.6.15 started today.  We were also able to retire our old release candidate numbering system in favor of true release candidate builds. 

No comments:

Post a Comment