This is expected. You will find below email exchange I got with Ron where I explain why.

// -------------------------------
// -------------------------------
Ron - Dec 15, 2012

I notice that the nightly build is still numbered 4.2.0 instead of 4.2.2-1 or such.

// -------------------------------
// -------------------------------
Jc - 12/15/12:

This is expected, The version 4.2.2-1 is a patch release build of the 4.2 branch. On the other hand, the main branch (trunk) doesn'have the commit specific to the versioning of the 4.2 branch.
I tried to illustrate it below.

   4.2.0                               4.3.0

--------#-----------------------------------#
\
\ --- 4.2.1---4.2.2----4.2.3

// -------------------------------
// -------------------------------
Ron - Sat, Dec 15, 2012

I guess, I need more education. I do not understand your explanation. What is the meaning of "the main branch doesn't have the commit specific to the versioning of the 4.2 branch"?

// -------------------------------
// -------------------------------
Jc - 12/15/12

Each time we create a release, we have to modify a file where the
revision is written. To save this revision update, a commit is created.
Then, a package is created based on this commit.

Since we have two branch for slicer development:

• trunk or master branch where all the active development is going
• 4.2 release maintenance branch

.. each time we create a patch release for 4.2, the commit representing
the update of the revision is only on the 4.2 branch. It means only this
branch will contain commit resulting in package like 4.2.1, 4.2.2 ....

Thanks
Jc

// -------------------------------
// -------------------------------
Ron - Sat, Dec 15, 2012

If I understnd properly, that means that all the bug fixes on 4.2.2 are not in the 4.2.0 branch?
This results in duplicate work?

// -------------------------------
// -------------------------------
Jc - Dec 15, 2012

In fact, the commit happening in the main (master/trunk) branch are backported to the maintenance branch. In other word, when a bug is fixed in the nightly, I select the associated commit and apply it on the maintenance branch, when I have enough small fixes ... I then create a patch release (4.2.1, 4.2.2, 4.2.3, ...)

Let's also note that major feature, change introducing redesign, ... are not backported .. these ones along with the regular fixes will be part of the next minor release: 4.3.0