[asterisk-dev] Asterisk 1.6.2.8 Now Available

[Leif Madsen]

Prince Singh wrote:
> I was just trying to find out the changes from 1.6.2.7 to 1.6.2.8, when 
> I noticed that the order of Change Log entries is slightly confusing 
> around when 1.6.2.7 was released.
> 
> Shouldn't it be always that the date decrements from top to bottom ?

Not necessarily, and likely not. Let me explain.

When we create a new release candidate (RC1 for example) for a new release, we 
tag it from the branch directly. This means whatever is currently in that branch 
(we'll use 1.6.2 as our example) is copied to a new tag.

So we take the current state of the 1.6.2 branch and copy that to our new tag, 
lets say 1.6.2.8-rc1.

If that is on May 1st, then the ChangeLog will be incremental up to that point 
and you will see "Asterisk 1.6.2.8-rc1 Released."

When we create a new release candidate for that tag, lets say 1.6.2.8-rc2, then 
we copy the existing 1.6.2.8-rc1 directly to 1.6.2.8-rc2, and then merge in the 
changes that we feel are necessary for a new release candidate (typically a 
regression or crash of some sort).

The key here is that during this time other changes continue to be put into the 
1.6.2 branch which will eventually become another release candidate in the 
future. Remember this as it will come into play in a moment.

So when we decide that 1.6.2.8-rc2 should be released as a full release, then we 
copy 1.6.2.8-rc2 to 1.6.2.8 tag, and modify the ChangeLog to state "Asterisk 
1.6.2.8 Released" which you'll see directly above the "Asterisk 1.6.2.8-rc2 
Released" note in the ChangeLog. This means no additional changes were done 
between 1.6.2.8-rc2 and 1.6.2.8 in the release cycle.

(Note that time does exist between the release candidates, perhaps a week or 
more, and during that time changes are going into the 1.6.2 branch.)

When the next release candidate is created, we pull it directly from the branch 
again, which will include all changes after the 1.6.2.8-rc1 was created. When 
this is done, we modify the ChangeLog manually to show the progression of issues 
in a particular release to be like so:

June 1 - 1.6.2.9-rc1 created
...
May 3 - Some change to go into 1.6.2.9
May 2 - Some change to go into 1.6.2.9
May 14 - 1.6.2.8 created
May 7 - 1.6.2.8-rc2 created
May 7 - Some change that caused 1.6.2.8-rc2 to be created
May 1 - 1.6.2.8-rc1 created

If we didn't put the dates of the 1.6.2.8-rc2 and 1.6.2.8 release down directly 
above the 1.6.2.8-rc1 release, then it would be confusing because you wouldn't 
know what changes were part of 1.6.2.8 (or what commits were part of 1.6.2.9).

Hope that helps explain why the dates are not necessarily perfectly linear.

Leif Madsen.