[asterisk-dev] Asterisk Now Available

Leif Madsen leif.madsen at asteriskdocs.org
Wed Jun 2 07:33:05 CDT 2010

Prince Singh wrote:
> I was just trying to find out the changes from to, when 
> I noticed that the order of Change Log entries is slightly confusing 
> around when 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

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

When we create a new release candidate for that tag, lets say, then 
we copy the existing directly to, 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 should be released as a full release, then we 
copy to tag, and modify the ChangeLog to state "Asterisk Released" which you'll see directly above the "Asterisk 
Released" note in the ChangeLog. This means no additional changes were done 
between and 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 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 - created
May 3 - Some change to go into
May 2 - Some change to go into
May 14 - created
May 7 - created
May 7 - Some change that caused to be created
May 1 - created

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

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

Leif Madsen.

More information about the asterisk-dev mailing list