Re: [asterisk-dev] tags on the main branches [was: Re: Minor Release Branches]

[Tzafrir Cohen]

On Fri, Dec 22, 2017 at 08:22:09AM -0700, George Joseph wrote:
> On Thu, Dec 21, 2017 at 1:44 PM, Corey Farrell  wrote:
> 
> > George asked that I post some scenarios where this would be useful.
> > 1. You are about to create updated asterisk package and want to quickly
> > scan the changes to 13 since latest 13.x.0 release to see if anything is a
> > 'must patch' for your deployments.  You can use 'tig' to review changes for
> > critical fixes until you reach the tag '13.x.0-rc1' (which you can see in
> > the list because the tag was merged).
> >
> 
> I didn't even know about tig.  There's always something to learn about the
> git ecosystem. :)

Git actually has some of this functionality built in.

Try adding to your ~/.gitconfig :

[alias]
lol = log --graph --decorate --pretty=oneline --abbrev-commit


With this, 'git lol' instead of 'git log' gixes you a commits graph with
all the branch heads and tags visible.

-- 
   Tzafrir Cohen
+972-50-7952406   mailto:tzafrir.co...@xorcom.com
http://www.xorcom.com

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] tags on the main branches [was: Re: Minor Release Branches]

[George Joseph]

On Fri, Dec 22, 2017 at 11:01 AM, Corey Farrell  wrote:

> On 12/22/2017 12:36 PM, George Joseph wrote:
>
>
>
> On Fri, Dec 22, 2017 at 9:50 AM, Corey Farrell  wrote:
>
>> On 12/22/2017 10:22 AM, George Joseph wrote:
>>
>>
>>
>> On Thu, Dec 21, 2017 at 1:44 PM, Corey Farrell  wrote:
>>
>>> George asked that I post some scenarios where this would be useful.
>>> 1. You are about to create updated asterisk package and want to quickly
>>> scan the changes to 13 since latest 13.x.0 release to see if anything is a
>>> 'must patch' for your deployments.  You can use 'tig' to review changes for
>>> critical fixes until you reach the tag '13.x.0-rc1' (which you can see in
>>> the list because the tag was merged).
>>>
>>
>> I didn't even know about tig.  There's always something to learn about
>> the git ecosystem. :)
>>
>>
>>
>>> I know the end result can be accomplished by other means, but not as
>>> easily.
>>>
>>> 2. You've created an automated test to try finding a performance
>>> regression.  The test runs asterisk under a profiler and stores results.
>>> Each revision you test needs a new file to store results - 'git describe'
>>> would provide an excellent filename that is unique per revision.
>>>
>>> One thing I'm not sure about is if we should only merge rc1 tags or if
>>> we should merge all new release tags.  At first all release tags seem
>>> reasonable, but the order of tags other than rc1 would be off.  rc1 is
>>> special because it would be merged back to mainline before anything else.
>>> Even 13.x.0 does not get cut until after other commits are merged to 13, so
>>> if we merged 13.19.0 to 13, the commits made since 13.19.0-rc1 would appear
>>> out of order (before 13.19.0).  The difference between rc1 and final
>>> release is always small, but the number of new commits to mainline between
>>> that time can be quite large.
>>>
>> So we would merge rc1's back to mainline but how about the point releases?
>> 13.19.0-rc1
>> 13.19.1  ??
>> 13.19.2  ??
>>
>> 13.18-cert1-rc1
>> 13.18-cert2 ??
>> 13.18-cert3 ??
>>
>>
>> Just to be clear certified branches would be untouched by this proposal.
>> Look at 'git log certified/13.13-cert9' - you will see the previous tagged
>> releases in the certified/13.13 release series.
>>
>> I think we should not do anything different with the point releases
>> (including 13.19.0) because of the commit order.  Think about when 13.18.4
>> were released.  If we merged it to 13 it would be in the wrong place on
>> 'git log 13'.  Easily 200 non-merge commits would appear after the 13.18.4
>> tag in the 13 branch, when in fact they are not part of the 13.18.4 tag.
>> My hope is that we can provide additional information, but only if the
>> information is accurate.
>>
>
> Sorry, I'm being thick...  So if it's only the rc1's then why won't an
> annotated tag do what you want without having to alter the mainline commit
> history with a merge?
>
>
> The whole point is for an annotated tag to be in the mainline commit
> history.  This way when you do 'tig 15' it will show where each release was
> split from mainline (the ones we merge in the future that is).
>

Sorry, yeah that's what I was talking about.  An annotated tag in the
mainline branches created at the point we create the release branches.

Here's how the 15 branch it would look in tig.  Mocked up of course.

$ tig
2017-12-18 13:23 Corey Farrell   o [15] CLI: Fix 'core set
debug channe
2017-12-18 13:23 Corey Farrell   o CLI: Fix 'core set debug
channel' co
2017-11-26 18:47 Alexander Traud o <15.1.0> translate:
Transcode siren1
2017-12-14 16:27 Corey Farrell   o res_clialiases: Fix
completion pass-
2017-08-04 17:25 Andrey Egorov   o <15.0.0> res_xmpp: Google
OAuth 2.0
2017-08-14 12:20 George Joseph   M─┐ Merge
"res_pjsip_outbound_registra
2017-08-02 18:44 Richard Mudgett │ o
res_pjsip_outbound_registration.c:
2017-08-14 12:20 George Joseph   M─│─┐ Merge changes from topic
'ASTERI

$ git log --oneline
4f54e20d80 (HEAD -> 15) CLI: Fix 'core set debug channel
779fc81793 CLI: Fix 'core set debug channel' completion
f2a35a941d (tag: 15.1.0) translate: Transcode siren14, s
aa3fb9887c res_clialiases: Fix completion pass-through.
4e11c2192f (tag: 15.0.0) res_xmpp: Google OAuth 2.0 prot
0442fcb586 Merge "res_pjsip_outbound_registration.c: Re-
6a736c3c0d Merge changes from topic 'ASTERISK-27147' int
c5618d7c29 Merge "res_pjsip_transport_management.c: Rena

$ git describe
15.1.0-2-g4f54e20d80


>
>
>
>
>> One last detail I don't know exactly how we deal with new major releases
>> (ie 16.0.0).  If I remember correctly we will release 16.0.0-beta1, but I
>> don't remember if that is the start of the 16.0 branch or if 16.0 starts
>> with rc1.  However it works my current proposal would be to merge the first
>> commit of 16.0 back to 16.
>>
>
> we manually cut the 16 branch from master before 

Re: [asterisk-dev] tags on the main branches [was: Re: Minor Release Branches]

[Corey Farrell]

On 12/22/2017 12:36 PM, George Joseph wrote:



On Fri, Dec 22, 2017 at 9:50 AM, Corey Farrell > wrote:


On 12/22/2017 10:22 AM, George Joseph wrote:



On Thu, Dec 21, 2017 at 1:44 PM, Corey Farrell > wrote:

George asked that I post some scenarios where this would be
useful.

1. You are about to create updated asterisk package and want
to quickly scan the changes to 13 since latest 13.x.0 release
to see if anything is a 'must patch' for your deployments. 
You can use 'tig' to review changes for critical fixes until
you reach the tag '13.x.0-rc1' (which you can see in the list
because the tag was merged).


I didn't even know about tig.  There's always something to learn
about the git ecosystem. :)

I know the end result can be accomplished by other means, but
not as easily.

2. You've created an automated test to try finding a
performance regression. The test runs asterisk under a
profiler and stores results.  Each revision you test needs a
new file to store results - 'git describe' would provide an
excellent filename that is unique per revision.

One thing I'm not sure about is if we should only merge rc1
tags or if we should merge all new release tags.  At first
all release tags seem reasonable, but the order of tags other
than rc1 would be off.  rc1 is special because it would be
merged back to mainline before anything else.  Even 13.x.0
does not get cut until after other commits are merged to 13,
so if we merged 13.19.0 to 13, the commits made since
13.19.0-rc1 would appear out of order (before 13.19.0). The
difference between rc1 and final release is always small, but
the number of new commits to mainline between that time can
be quite large.

So we would merge rc1's back to mainline but how about the point
releases?
13.19.0-rc1
13.19.1  ??
13.19.2  ??

13.18-cert1-rc1
13.18-cert2 ??
13.18-cert3 ??


Just to be clear certified branches would be untouched by this
proposal.  Look at 'git log certified/13.13-cert9' - you will see
the previous tagged releases in the certified/13.13 release series.

I think we should not do anything different with the point
releases (including 13.19.0) because of the commit order.  Think
about when 13.18.4 were released.  If we merged it to 13 it would
be in the wrong place on 'git log 13'.  Easily 200 non-merge
commits would appear after the 13.18.4 tag in the 13 branch, when
in fact they are not part of the 13.18.4 tag.  My hope is that we
can provide additional information, but only if the information is
accurate.


Sorry, I'm being thick...  So if it's only the rc1's then why won't an 
annotated tag do what you want without having to alter the mainline 
commit history with a merge?


The whole point is for an annotated tag to be in the mainline commit 
history.  This way when you do 'tig 15' it will show where each release 
was split from mainline (the ones we merge in the future that is).



One last detail I don't know exactly how we deal with new major
releases (ie 16.0.0).  If I remember correctly we will release
16.0.0-beta1, but I don't remember if that is the start of the
16.0 branch or if 16.0 starts with rc1.  However it works my
current proposal would be to merge the first commit of 16.0 back
to 16.


we manually cut the 16 branch from master before anything then the 
release process creates 16.0 when we release beta1.


In that case we would only merge 16.0.0-beta1 back to 16 (the split 
point), we would not merge 16.0.0-rc1 since it would be behind 16 at the 
time of creation.




Tzafrir I haven't heard from you since I joined your new thread. 
If we were to merge the rc1's back to mainline so that mainline
knew about the "split point", would this satisfy your request? 
Also was your intent to say "we should do this first before
deleting minor branches"?  Do you object if we proceed with
removal of minor branches or does your request need to be
completed first?





On 12/21/2017 10:45 AM, Corey Farrell wrote:

I just read `git help merge` again and I think the solution
is 'git checkout 13 && git merge --strategy ours
13.19.0-rc1'.  This would effectively tell git that '13'
already contains 13.19.0-rc1, but without actually trying to
pull any changes to 13.  This merge would be the final step
of mkrelease.py.

No changes will be needed to our handling of '.lastclean',
please ignore those comments as I was wrong.

On 12/21/2017 08:19 AM, George Joseph wrote:



On Wed, Dec 20, 2017 at 3:14 PM, Corey Farrell

Re: [asterisk-dev] tags on the main branches [was: Re: Minor Release Branches]

[George Joseph]

On Fri, Dec 22, 2017 at 9:50 AM, Corey Farrell  wrote:

> On 12/22/2017 10:22 AM, George Joseph wrote:
>
>
>
> On Thu, Dec 21, 2017 at 1:44 PM, Corey Farrell  wrote:
>
>> George asked that I post some scenarios where this would be useful.
>> 1. You are about to create updated asterisk package and want to quickly
>> scan the changes to 13 since latest 13.x.0 release to see if anything is a
>> 'must patch' for your deployments.  You can use 'tig' to review changes for
>> critical fixes until you reach the tag '13.x.0-rc1' (which you can see in
>> the list because the tag was merged).
>>
>
> I didn't even know about tig.  There's always something to learn about the
> git ecosystem. :)
>
>
>
>> I know the end result can be accomplished by other means, but not as
>> easily.
>>
>> 2. You've created an automated test to try finding a performance
>> regression.  The test runs asterisk under a profiler and stores results.
>> Each revision you test needs a new file to store results - 'git describe'
>> would provide an excellent filename that is unique per revision.
>>
>> One thing I'm not sure about is if we should only merge rc1 tags or if we
>> should merge all new release tags.  At first all release tags seem
>> reasonable, but the order of tags other than rc1 would be off.  rc1 is
>> special because it would be merged back to mainline before anything else.
>> Even 13.x.0 does not get cut until after other commits are merged to 13, so
>> if we merged 13.19.0 to 13, the commits made since 13.19.0-rc1 would appear
>> out of order (before 13.19.0).  The difference between rc1 and final
>> release is always small, but the number of new commits to mainline between
>> that time can be quite large.
>>
> So we would merge rc1's back to mainline but how about the point releases?
> 13.19.0-rc1
> 13.19.1  ??
> 13.19.2  ??
>
> 13.18-cert1-rc1
> 13.18-cert2 ??
> 13.18-cert3 ??
>
>
> Just to be clear certified branches would be untouched by this proposal.
> Look at 'git log certified/13.13-cert9' - you will see the previous tagged
> releases in the certified/13.13 release series.
>
> I think we should not do anything different with the point releases
> (including 13.19.0) because of the commit order.  Think about when 13.18.4
> were released.  If we merged it to 13 it would be in the wrong place on
> 'git log 13'.  Easily 200 non-merge commits would appear after the 13.18.4
> tag in the 13 branch, when in fact they are not part of the 13.18.4 tag.
> My hope is that we can provide additional information, but only if the
> information is accurate.
>

Sorry, I'm being thick...  So if it's only the rc1's then why won't an
annotated tag do what you want without having to alter the mainline commit
history with a merge?




>
> One last detail I don't know exactly how we deal with new major releases
> (ie 16.0.0).  If I remember correctly we will release 16.0.0-beta1, but I
> don't remember if that is the start of the 16.0 branch or if 16.0 starts
> with rc1.  However it works my current proposal would be to merge the first
> commit of 16.0 back to 16.
>

we manually cut the 16 branch from master before anything then the release
process creates 16.0 when we release beta1.



>
> Tzafrir I haven't heard from you since I joined your new thread.  If we
> were to merge the rc1's back to mainline so that mainline knew about the
> "split point", would this satisfy your request?  Also was your intent to
> say "we should do this first before deleting minor branches"?  Do you
> object if we proceed with removal of minor branches or does your request
> need to be completed first?
>
>
>
>
>> On 12/21/2017 10:45 AM, Corey Farrell wrote:
>>
>> I just read `git help merge` again and I think the solution is 'git
>> checkout 13 && git merge --strategy ours 13.19.0-rc1'.  This would
>> effectively tell git that '13' already contains 13.19.0-rc1, but without
>> actually trying to pull any changes to 13.  This merge would be the final
>> step of mkrelease.py.
>>
>> No changes will be needed to our handling of '.lastclean', please ignore
>> those comments as I was wrong.
>>
>> On 12/21/2017 08:19 AM, George Joseph wrote:
>>
>>
>>
>> On Wed, Dec 20, 2017 at 3:14 PM, Corey Farrell  wrote:
>>
>>> One thing that might improve this is if releases were merged back to the
>>> major branch.  Currently the commit "Update for 13.19.0-rc1" is on the
>>> 13.19 branch and tagged as 13.19.0-rc1.  I believe that if we added 'git
>>> checkout 13 && git merge 13.19.0-rc1' we would get better information from
>>> 'git describe 13' and tags would appear in 'git log 13 --oneline'.  This
>>> would continue working even after we delete the minor branches.
>>>
>> Sounds reasonable.
>>
>>
>>
>>> As a test I just ran 'git merge 13.18.4' from the current 13 branch.
>>> The merge did have 2 conflicts but that's because 13.18 was branched so
>>> long ago and a couple files that were modified in minor releases have since
>>> been 

Re: [asterisk-dev] tags on the main branches [was: Re: Minor Release Branches]

[Corey Farrell]

On 12/22/2017 10:22 AM, George Joseph wrote:



On Thu, Dec 21, 2017 at 1:44 PM, Corey Farrell > wrote:


George asked that I post some scenarios where this would be useful.

1. You are about to create updated asterisk package and want to
quickly scan the changes to 13 since latest 13.x.0 release to see
if anything is a 'must patch' for your deployments.  You can use
'tig' to review changes for critical fixes until you reach the tag
'13.x.0-rc1' (which you can see in the list because the tag was
merged).


I didn't even know about tig.  There's always something to learn about 
the git ecosystem. :)


I know the end result can be accomplished by other means, but not
as easily.

2. You've created an automated test to try finding a performance
regression.  The test runs asterisk under a profiler and stores
results.  Each revision you test needs a new file to store results
- 'git describe' would provide an excellent filename that is
unique per revision.

One thing I'm not sure about is if we should only merge rc1 tags
or if we should merge all new release tags.  At first all release
tags seem reasonable, but the order of tags other than rc1 would
be off.  rc1 is special because it would be merged back to
mainline before anything else.  Even 13.x.0 does not get cut until
after other commits are merged to 13, so if we merged 13.19.0 to
13, the commits made since 13.19.0-rc1 would appear out of order
(before 13.19.0).  The difference between rc1 and final release is
always small, but the number of new commits to mainline between
that time can be quite large.

So we would merge rc1's back to mainline but how about the point releases?
13.19.0-rc1
13.19.1  ??
13.19.2  ??

13.18-cert1-rc1
13.18-cert2 ??
13.18-cert3 ??


Just to be clear certified branches would be untouched by this 
proposal.  Look at 'git log certified/13.13-cert9' - you will see the 
previous tagged releases in the certified/13.13 release series.


I think we should not do anything different with the point releases 
(including 13.19.0) because of the commit order.  Think about when 
13.18.4 were released.  If we merged it to 13 it would be in the wrong 
place on 'git log 13'.  Easily 200 non-merge commits would appear after 
the 13.18.4 tag in the 13 branch, when in fact they are not part of the 
13.18.4 tag.  My hope is that we can provide additional information, but 
only if the information is accurate.


One last detail I don't know exactly how we deal with new major releases 
(ie 16.0.0).  If I remember correctly we will release 16.0.0-beta1, but 
I don't remember if that is the start of the 16.0 branch or if 16.0 
starts with rc1.  However it works my current proposal would be to merge 
the first commit of 16.0 back to 16.


Tzafrir I haven't heard from you since I joined your new thread.  If we 
were to merge the rc1's back to mainline so that mainline knew about the 
"split point", would this satisfy your request?  Also was your intent to 
say "we should do this first before deleting minor branches"?  Do you 
object if we proceed with removal of minor branches or does your request 
need to be completed first?





On 12/21/2017 10:45 AM, Corey Farrell wrote:

I just read `git help merge` again and I think the solution is
'git checkout 13 && git merge --strategy ours 13.19.0-rc1'.  This
would effectively tell git that '13' already contains
13.19.0-rc1, but without actually trying to pull any changes to
13.  This merge would be the final step of mkrelease.py.

No changes will be needed to our handling of '.lastclean', please
ignore those comments as I was wrong.

On 12/21/2017 08:19 AM, George Joseph wrote:



On Wed, Dec 20, 2017 at 3:14 PM, Corey Farrell > wrote:

One thing that might improve this is if releases were merged
back to the major branch.  Currently the commit "Update for
13.19.0-rc1" is on the 13.19 branch and tagged as
13.19.0-rc1.  I believe that if we added 'git checkout 13 &&
git merge 13.19.0-rc1' we would get better information from
'git describe 13' and tags would appear in 'git log 13
--oneline'.  This would continue working even after we
delete the minor branches.

Sounds reasonable.

As a test I just ran 'git merge 13.18.4' from the current 13
branch.  The merge did have 2 conflicts but that's because
13.18 was branched so long ago and a couple files that were
modified in minor releases have since been modified again or
deleted.  Then I ran 'git describe 13', it said
'13.18.4-404-gd5d67bb1f4'.  This tells us that my local
branch had about 404 commits (including merges) that are not
part of 13.18.0-rc1 (the point where 13.18 diverged from 13
because 13.18.3 was 

Re: [asterisk-dev] tags on the main branches [was: Re: Minor Release Branches]

[George Joseph]

On Thu, Dec 21, 2017 at 1:44 PM, Corey Farrell  wrote:

> George asked that I post some scenarios where this would be useful.
> 1. You are about to create updated asterisk package and want to quickly
> scan the changes to 13 since latest 13.x.0 release to see if anything is a
> 'must patch' for your deployments.  You can use 'tig' to review changes for
> critical fixes until you reach the tag '13.x.0-rc1' (which you can see in
> the list because the tag was merged).
>

I didn't even know about tig.  There's always something to learn about the
git ecosystem. :)



> I know the end result can be accomplished by other means, but not as
> easily.
>
> 2. You've created an automated test to try finding a performance
> regression.  The test runs asterisk under a profiler and stores results.
> Each revision you test needs a new file to store results - 'git describe'
> would provide an excellent filename that is unique per revision.
>
> One thing I'm not sure about is if we should only merge rc1 tags or if we
> should merge all new release tags.  At first all release tags seem
> reasonable, but the order of tags other than rc1 would be off.  rc1 is
> special because it would be merged back to mainline before anything else.
> Even 13.x.0 does not get cut until after other commits are merged to 13, so
> if we merged 13.19.0 to 13, the commits made since 13.19.0-rc1 would appear
> out of order (before 13.19.0).  The difference between rc1 and final
> release is always small, but the number of new commits to mainline between
> that time can be quite large.
>
So we would merge rc1's back to mainline but how about the point releases?
13.19.0-rc1
13.19.1  ??
13.19.2  ??

13.18-cert1-rc1
13.18-cert2 ??
13.18-cert3 ??


> On 12/21/2017 10:45 AM, Corey Farrell wrote:
>
> I just read `git help merge` again and I think the solution is 'git
> checkout 13 && git merge --strategy ours 13.19.0-rc1'.  This would
> effectively tell git that '13' already contains 13.19.0-rc1, but without
> actually trying to pull any changes to 13.  This merge would be the final
> step of mkrelease.py.
>
> No changes will be needed to our handling of '.lastclean', please ignore
> those comments as I was wrong.
>
> On 12/21/2017 08:19 AM, George Joseph wrote:
>
>
>
> On Wed, Dec 20, 2017 at 3:14 PM, Corey Farrell  wrote:
>
>> One thing that might improve this is if releases were merged back to the
>> major branch.  Currently the commit "Update for 13.19.0-rc1" is on the
>> 13.19 branch and tagged as 13.19.0-rc1.  I believe that if we added 'git
>> checkout 13 && git merge 13.19.0-rc1' we would get better information from
>> 'git describe 13' and tags would appear in 'git log 13 --oneline'.  This
>> would continue working even after we delete the minor branches.
>>
> Sounds reasonable.
>
>
>
>> As a test I just ran 'git merge 13.18.4' from the current 13 branch.  The
>> merge did have 2 conflicts but that's because 13.18 was branched so long
>> ago and a couple files that were modified in minor releases have since been
>> modified again or deleted.  Then I ran 'git describe 13', it said
>> '13.18.4-404-gd5d67bb1f4'.  This tells us that my local branch had about
>> 404 commits (including merges) that are not part of 13.18.0-rc1 (the point
>> where 13.18 diverged from 13 because 13.18.3 was not merged back).  Merging
>> each tag as soon as it's created would make the results more accurate. and
>> (almost always) eliminate merge conflicts.
>>
> "almost always" will be an issue since it's the scripts that do the work.
> It's kinda frustrating already when you're trying to get releases out the
> door and something goes wrong with the script.  What conditions do you
> think might still cause merge conflicts?
>
>
>> The only wrinkle in this plan is that the '.lastclean' file is created on
>> the releases but it's listed in .gitignore.  I think we might be able to
>> just get rid of the .lastclean and .cleancount files.  This Makefile hack
>> predates the use of SVN and I don't think it's necessary.  One thing it
>> does do is try to enable the astdb2sqlite3 utility, but Berkely DB was last
>> used in Asterisk 1.8.  The default is for that utility to be enabled,
>> that's enough.  In addition the mkrelease script actually copies
>> .cleancount to .lastclean, I think that means it's disabled for releases.
>>
> These kind of things we can alter to suite our needs so there shouldn't be
> an issue.
>
>
>>
>> On 12/20/2017 12:58 PM, George Joseph wrote:
>>
>>
>>
>> On Wed, Dec 20, 2017 at 8:14 AM, Tzafrir Cohen 
>> wrote:
>>
>>> On Wed, Dec 20, 2017 at 07:50:03AM -0700, George Joseph wrote:
>>> > On Wed, Dec 20, 2017 at 2:44 AM, Tzafrir Cohen <
>>> tzafrir.co...@xorcom.com>
>>> > wrote:
>>> >
>>> > > Off-topic:
>>> > >
>>> > > On Tue, Dec 19, 2017 at 01:50:03PM -0700, George Joseph wrote:
>>> > >
>>> > > > Thankfully we tag EVERYTHING! :)
>>> > >
>>> > > asterisk(13)$ git describe
>>> > > 

Re: [asterisk-dev] tags on the main branches [was: Re: Minor Release Branches]

[Corey Farrell]

George asked that I post some scenarios where this would be useful.

1. You are about to create updated asterisk package and want to quickly 
scan the changes to 13 since latest 13.x.0 release to see if anything is 
a 'must patch' for your deployments.  You can use 'tig' to review 
changes for critical fixes until you reach the tag '13.x.0-rc1' (which 
you can see in the list because the tag was merged).  I know the end 
result can be accomplished by other means, but not as easily.


2. You've created an automated test to try finding a performance 
regression.  The test runs asterisk under a profiler and stores 
results.  Each revision you test needs a new file to store results - 
'git describe' would provide an excellent filename that is unique per 
revision.


One thing I'm not sure about is if we should only merge rc1 tags or if 
we should merge all new release tags.  At first all release tags seem 
reasonable, but the order of tags other than rc1 would be off.  rc1 is 
special because it would be merged back to mainline before anything 
else.  Even 13.x.0 does not get cut until after other commits are merged 
to 13, so if we merged 13.19.0 to 13, the commits made since 13.19.0-rc1 
would appear out of order (before 13.19.0).  The difference between rc1 
and final release is always small, but the number of new commits to 
mainline between that time can be quite large.



On 12/21/2017 10:45 AM, Corey Farrell wrote:
I just read `git help merge` again and I think the solution is 'git 
checkout 13 && git merge --strategy ours 13.19.0-rc1'.  This would 
effectively tell git that '13' already contains 13.19.0-rc1, but 
without actually trying to pull any changes to 13.  This merge would 
be the final step of mkrelease.py.


No changes will be needed to our handling of '.lastclean', please 
ignore those comments as I was wrong.


On 12/21/2017 08:19 AM, George Joseph wrote:



On Wed, Dec 20, 2017 at 3:14 PM, Corey Farrell > wrote:


One thing that might improve this is if releases were merged back
to the major branch.  Currently the commit "Update for
13.19.0-rc1" is on the 13.19 branch and tagged as 13.19.0-rc1.  I
believe that if we added 'git checkout 13 && git merge
13.19.0-rc1' we would get better information from 'git describe
13' and tags would appear in 'git log 13 --oneline'.  This would
continue working even after we delete the minor branches.

Sounds reasonable.

As a test I just ran 'git merge 13.18.4' from the current 13
branch.  The merge did have 2 conflicts but that's because 13.18
was branched so long ago and a couple files that were modified in
minor releases have since been modified again or deleted. Then I
ran 'git describe 13', it said '13.18.4-404-gd5d67bb1f4'.  This
tells us that my local branch had about 404 commits (including
merges) that are not part of 13.18.0-rc1 (the point where 13.18
diverged from 13 because 13.18.3 was not merged back).  Merging
each tag as soon as it's created would make the results more
accurate. and (almost always) eliminate merge conflicts.

"almost always" will be an issue since it's the scripts that do the 
work.  It's kinda frustrating already when you're trying to get 
releases out the door and something goes wrong with the script.  What 
conditions do you think might still cause merge conflicts?


The only wrinkle in this plan is that the '.lastclean' file is
created on the releases but it's listed in .gitignore.  I think
we might be able to just get rid of the .lastclean and
.cleancount files.  This Makefile hack predates the use of SVN
and I don't think it's necessary.  One thing it does do is try to
enable the astdb2sqlite3 utility, but Berkely DB was last used in
Asterisk 1.8.  The default is for that utility to be enabled,
that's enough.  In addition the mkrelease script actually copies
.cleancount to .lastclean, I think that means it's disabled for
releases.

These kind of things we can alter to suite our needs so there 
shouldn't be an issue.



On 12/20/2017 12:58 PM, George Joseph wrote:



On Wed, Dec 20, 2017 at 8:14 AM, Tzafrir Cohen
> wrote:

On Wed, Dec 20, 2017 at 07:50:03AM -0700, George Joseph wrote:
> On Wed, Dec 20, 2017 at 2:44 AM, Tzafrir Cohen
>
> wrote:
>
> > Off-topic:
> >
> > On Tue, Dec 19, 2017 at 01:50:03PM -0700, George Joseph
wrote:
> >
> > > Thankfully we tag EVERYTHING! :)
> >
> > asterisk(13)$ git describe
> > 13.15.0-rc1-908-ge31e3b581b
> >
> > asterisk(14)$ git describe
> > fatal: No tags can describe
'fb18797ae09a685ec71101499fb1c1c606b16397'.
> > Try --always, or create some tags.
> 

Re: [asterisk-dev] tags on the main branches [was: Re: Minor Release Branches]

[Corey Farrell]

I just read `git help merge` again and I think the solution is 'git 
checkout 13 && git merge --strategy ours 13.19.0-rc1'.  This would 
effectively tell git that '13' already contains 13.19.0-rc1, but without 
actually trying to pull any changes to 13.  This merge would be the 
final step of mkrelease.py.


No changes will be needed to our handling of '.lastclean', please ignore 
those comments as I was wrong.


On 12/21/2017 08:19 AM, George Joseph wrote:



On Wed, Dec 20, 2017 at 3:14 PM, Corey Farrell > wrote:


One thing that might improve this is if releases were merged back
to the major branch.  Currently the commit "Update for
13.19.0-rc1" is on the 13.19 branch and tagged as 13.19.0-rc1.  I
believe that if we added 'git checkout 13 && git merge
13.19.0-rc1' we would get better information from 'git describe
13' and tags would appear in 'git log 13 --oneline'.  This would
continue working even after we delete the minor branches.

Sounds reasonable.

As a test I just ran 'git merge 13.18.4' from the current 13
branch.  The merge did have 2 conflicts but that's because 13.18
was branched so long ago and a couple files that were modified in
minor releases have since been modified again or deleted.  Then I
ran 'git describe 13', it said '13.18.4-404-gd5d67bb1f4'.  This
tells us that my local branch had about 404 commits (including
merges) that are not part of 13.18.0-rc1 (the point where 13.18
diverged from 13 because 13.18.3 was not merged back).  Merging
each tag as soon as it's created would make the results more
accurate. and (almost always) eliminate merge conflicts.

"almost always" will be an issue since it's the scripts that do the 
work.  It's kinda frustrating already when you're trying to get 
releases out the door and something goes wrong with the script.  What 
conditions do you think might still cause merge conflicts?


The only wrinkle in this plan is that the '.lastclean' file is
created on the releases but it's listed in .gitignore.  I think we
might be able to just get rid of the .lastclean and .cleancount
files. This Makefile hack predates the use of SVN and I don't
think it's necessary.  One thing it does do is try to enable the
astdb2sqlite3 utility, but Berkely DB was last used in Asterisk
1.8.  The default is for that utility to be enabled, that's
enough.  In addition the mkrelease script actually copies
.cleancount to .lastclean, I think that means it's disabled for
releases.

These kind of things we can alter to suite our needs so there 
shouldn't be an issue.



On 12/20/2017 12:58 PM, George Joseph wrote:



On Wed, Dec 20, 2017 at 8:14 AM, Tzafrir Cohen
> wrote:

On Wed, Dec 20, 2017 at 07:50:03AM -0700, George Joseph wrote:
> On Wed, Dec 20, 2017 at 2:44 AM, Tzafrir Cohen
>
> wrote:
>
> > Off-topic:
> >
> > On Tue, Dec 19, 2017 at 01:50:03PM -0700, George Joseph
wrote:
> >
> > > Thankfully we tag EVERYTHING! :)
> >
> > asterisk(13)$ git describe
> > 13.15.0-rc1-908-ge31e3b581b
> >
> > asterisk(14)$ git describe
> > fatal: No tags can describe
'fb18797ae09a685ec71101499fb1c1c606b16397'.
> > Try --always, or create some tags.
> >
> > asterisk(15)$ git describe
> > fatal: No tags can describe
'd312068ee93ff8ce97b464f3c2ff3304e15cb3fe'.
> > Try --always, or create some tags.
> >
> >
> > I wasted half an hour yesterday trying to find out why a
build sis not
> > switch from master to 13, only to realize that the name
of the git
> > branch in the version string is always "master".
> >
> > We tag everything. But only well after it was branched
from the main
> >
> branch.
> >
>
> I'm not following you.
>
> We tag every release...
>
> $ git checkout 13.18.4
> HEAD is now at f4644317b7... Update for 13.18.4
> $ git describe
> 13.18.4


> $ git checkout 13.18
> Switched to branch '13.18'
> Your branch is up-to-date with 'gerrit/13.18'.
> $ git describe
> 13.18.4


> $
>
> We have to create the minor release branch (13.18) and do
the work there so
> that patch releases (13.18.4) are based on the minor
release branch, not
> the major branch.

Those branches are likewise short-lived branches (at least
with respect
to the number of commits). Real work is done on master, 13,
15 and such.
But when I'm on such a branch, I 

Re: [asterisk-dev] tags on the main branches [was: Re: Minor Release Branches]

[George Joseph]

On Wed, Dec 20, 2017 at 3:14 PM, Corey Farrell  wrote:

> One thing that might improve this is if releases were merged back to the
> major branch.  Currently the commit "Update for 13.19.0-rc1" is on the
> 13.19 branch and tagged as 13.19.0-rc1.  I believe that if we added 'git
> checkout 13 && git merge 13.19.0-rc1' we would get better information from
> 'git describe 13' and tags would appear in 'git log 13 --oneline'.  This
> would continue working even after we delete the minor branches.
>
Sounds reasonable.



> As a test I just ran 'git merge 13.18.4' from the current 13 branch.  The
> merge did have 2 conflicts but that's because 13.18 was branched so long
> ago and a couple files that were modified in minor releases have since been
> modified again or deleted.  Then I ran 'git describe 13', it said
> '13.18.4-404-gd5d67bb1f4'.  This tells us that my local branch had about
> 404 commits (including merges) that are not part of 13.18.0-rc1 (the point
> where 13.18 diverged from 13 because 13.18.3 was not merged back).  Merging
> each tag as soon as it's created would make the results more accurate. and
> (almost always) eliminate merge conflicts.
>
"almost always" will be an issue since it's the scripts that do the work.
It's kinda frustrating already when you're trying to get releases out the
door and something goes wrong with the script.  What conditions do you
think might still cause merge conflicts?


> The only wrinkle in this plan is that the '.lastclean' file is created on
> the releases but it's listed in .gitignore.  I think we might be able to
> just get rid of the .lastclean and .cleancount files.  This Makefile hack
> predates the use of SVN and I don't think it's necessary.  One thing it
> does do is try to enable the astdb2sqlite3 utility, but Berkely DB was last
> used in Asterisk 1.8.  The default is for that utility to be enabled,
> that's enough.  In addition the mkrelease script actually copies
> .cleancount to .lastclean, I think that means it's disabled for releases.
>
These kind of things we can alter to suite our needs so there shouldn't be
an issue.


>
> On 12/20/2017 12:58 PM, George Joseph wrote:
>
>
>
> On Wed, Dec 20, 2017 at 8:14 AM, Tzafrir Cohen 
> wrote:
>
>> On Wed, Dec 20, 2017 at 07:50:03AM -0700, George Joseph wrote:
>> > On Wed, Dec 20, 2017 at 2:44 AM, Tzafrir Cohen <
>> tzafrir.co...@xorcom.com>
>> > wrote:
>> >
>> > > Off-topic:
>> > >
>> > > On Tue, Dec 19, 2017 at 01:50:03PM -0700, George Joseph wrote:
>> > >
>> > > > Thankfully we tag EVERYTHING! :)
>> > >
>> > > asterisk(13)$ git describe
>> > > 13.15.0-rc1-908-ge31e3b581b
>> > >
>> > > asterisk(14)$ git describe
>> > > fatal: No tags can describe 'fb18797ae09a685ec71101499fb1c
>> 1c606b16397'.
>> > > Try --always, or create some tags.
>> > >
>> > > asterisk(15)$ git describe
>> > > fatal: No tags can describe 'd312068ee93ff8ce97b464f3c2ff3
>> 304e15cb3fe'.
>> > > Try --always, or create some tags.
>> > >
>> > >
>> > > I wasted half an hour yesterday trying to find out why a build sis not
>> > > switch from master to 13, only to realize that the name of the git
>> > > branch in the version string is always "master".
>> > >
>> > > We tag everything. But only well after it was branched from the main
>> > >
>> > branch.
>> > >
>> >
>> > I'm not following you.
>> >
>> > We tag every release...
>> >
>> > $ git checkout 13.18.4
>> > HEAD is now at f4644317b7... Update for 13.18.4
>> > $ git describe
>> > 13.18.4
>>
>>
>> > $ git checkout 13.18
>> > Switched to branch '13.18'
>> > Your branch is up-to-date with 'gerrit/13.18'.
>> > $ git describe
>> > 13.18.4
>>
>>
>> > $
>> >
>> > We have to create the minor release branch (13.18) and do the work
>> there so
>> > that patch releases (13.18.4) are based on the minor release branch, not
>> > the major branch.
>>
>> Those branches are likewise short-lived branches (at least with respect
>> to the number of commits). Real work is done on master, 13, 15 and such.
>> But when I'm on such a branch, I can't ask git on which branch I am (not
>> to mention: at which stage in it).
>>
>
>  I _think_ I understand now.
>
>>
>> For instance: maybe whenever you tag a new release branch (e.g. 13.18),
>> tag the split point as something like "13.18.base" or "base.13.18"?
>>
>
> Well, that's easy enough.  Toss us an issue for it.
>
>
>>
>> But maybe it's just me and branches 13 and 15 are not widely used (for
>> master it is irrelevant anyway).
>>
>> --
>>Tzafrir Cohen
>> +972-50-7952406   mailto:tzafrir.co...@xorcom.com
>> http://www.xorcom.com
>>
>> --
>> _
>> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>>
>> asterisk-dev mailing list
>> To UNSUBSCRIBE or update options visit:
>>http://lists.digium.com/mailman/listinfo/asterisk-dev
>>
>
>
>
> --
> George Joseph
> Digium, Inc. | Software Developer
> 445 Jan Davis 

Re: [asterisk-dev] tags on the main branches [was: Re: Minor Release Branches]

[Corey Farrell]

One thing that might improve this is if releases were merged back to the 
major branch.  Currently the commit "Update for 13.19.0-rc1" is on the 
13.19 branch and tagged as 13.19.0-rc1.  I believe that if we added 'git 
checkout 13 && git merge 13.19.0-rc1' we would get better information 
from 'git describe 13' and tags would appear in 'git log 13 --oneline'.  
This would continue working even after we delete the minor branches.


As a test I just ran 'git merge 13.18.4' from the current 13 branch.  
The merge did have 2 conflicts but that's because 13.18 was branched so 
long ago and a couple files that were modified in minor releases have 
since been modified again or deleted.  Then I ran 'git describe 13', it 
said '13.18.4-404-gd5d67bb1f4'.  This tells us that my local branch had 
about 404 commits (including merges) that are not part of 13.18.0-rc1 
(the point where 13.18 diverged from 13 because 13.18.3 was not merged 
back).  Merging each tag as soon as it's created would make the results 
more accurate. and (almost always) eliminate merge conflicts.


The only wrinkle in this plan is that the '.lastclean' file is created 
on the releases but it's listed in .gitignore.  I think we might be able 
to just get rid of the .lastclean and .cleancount files.  This Makefile 
hack predates the use of SVN and I don't think it's necessary.  One 
thing it does do is try to enable the astdb2sqlite3 utility, but Berkely 
DB was last used in Asterisk 1.8.  The default is for that utility to be 
enabled, that's enough.  In addition the mkrelease script actually 
copies .cleancount to .lastclean, I think that means it's disabled for 
releases.



On 12/20/2017 12:58 PM, George Joseph wrote:



On Wed, Dec 20, 2017 at 8:14 AM, Tzafrir Cohen 
> wrote:


On Wed, Dec 20, 2017 at 07:50:03AM -0700, George Joseph wrote:
> On Wed, Dec 20, 2017 at 2:44 AM, Tzafrir Cohen
>
> wrote:
>
> > Off-topic:
> >
> > On Tue, Dec 19, 2017 at 01:50:03PM -0700, George Joseph wrote:
> >
> > > Thankfully we tag EVERYTHING! :)
> >
> > asterisk(13)$ git describe
> > 13.15.0-rc1-908-ge31e3b581b
> >
> > asterisk(14)$ git describe
> > fatal: No tags can describe
'fb18797ae09a685ec71101499fb1c1c606b16397'.
> > Try --always, or create some tags.
> >
> > asterisk(15)$ git describe
> > fatal: No tags can describe
'd312068ee93ff8ce97b464f3c2ff3304e15cb3fe'.
> > Try --always, or create some tags.
> >
> >
> > I wasted half an hour yesterday trying to find out why a build
sis not
> > switch from master to 13, only to realize that the name of the git
> > branch in the version string is always "master".
> >
> > We tag everything. But only well after it was branched from
the main
> >
> branch.
> >
>
> I'm not following you.
>
> We tag every release...
>
> $ git checkout 13.18.4
> HEAD is now at f4644317b7... Update for 13.18.4
> $ git describe
> 13.18.4


> $ git checkout 13.18
> Switched to branch '13.18'
> Your branch is up-to-date with 'gerrit/13.18'.
> $ git describe
> 13.18.4


> $
>
> We have to create the minor release branch (13.18) and do the
work there so
> that patch releases (13.18.4) are based on the minor release
branch, not
> the major branch.

Those branches are likewise short-lived branches (at least with
respect
to the number of commits). Real work is done on master, 13, 15 and
such.
But when I'm on such a branch, I can't ask git on which branch I
am (not
to mention: at which stage in it).


 I _think_ I understand now.


For instance: maybe whenever you tag a new release branch (e.g.
13.18),
tag the split point as something like "13.18.base" or "base.13.18"?


Well, that's easy enough.  Toss us an issue for it.


But maybe it's just me and branches 13 and 15 are not widely used (for
master it is irrelevant anyway).

--
               Tzafrir Cohen
+972-50-7952406           mailto:tzafrir.co...@xorcom.com

http://www.xorcom.com

--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-dev





--
George Joseph
Digium, Inc. | Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - US
Check us out at: www.digium.com  & 
www.asterisk.org 






-- 
_
-- Bandwidth and Colocation Provided by 

Re: [asterisk-dev] tags on the main branches [was: Re: Minor Release Branches]

[George Joseph]

On Wed, Dec 20, 2017 at 8:14 AM, Tzafrir Cohen 
wrote:

> On Wed, Dec 20, 2017 at 07:50:03AM -0700, George Joseph wrote:
> > On Wed, Dec 20, 2017 at 2:44 AM, Tzafrir Cohen  >
> > wrote:
> >
> > > Off-topic:
> > >
> > > On Tue, Dec 19, 2017 at 01:50:03PM -0700, George Joseph wrote:
> > >
> > > > Thankfully we tag EVERYTHING! :)
> > >
> > > asterisk(13)$ git describe
> > > 13.15.0-rc1-908-ge31e3b581b
> > >
> > > asterisk(14)$ git describe
> > > fatal: No tags can describe 'fb18797ae09a685ec71101499fb1c1
> c606b16397'.
> > > Try --always, or create some tags.
> > >
> > > asterisk(15)$ git describe
> > > fatal: No tags can describe 'd312068ee93ff8ce97b464f3c2ff33
> 04e15cb3fe'.
> > > Try --always, or create some tags.
> > >
> > >
> > > I wasted half an hour yesterday trying to find out why a build sis not
> > > switch from master to 13, only to realize that the name of the git
> > > branch in the version string is always "master".
> > >
> > > We tag everything. But only well after it was branched from the main
> > >
> > branch.
> > >
> >
> > I'm not following you.
> >
> > We tag every release...
> >
> > $ git checkout 13.18.4
> > HEAD is now at f4644317b7... Update for 13.18.4
> > $ git describe
> > 13.18.4
>
>
> > $ git checkout 13.18
> > Switched to branch '13.18'
> > Your branch is up-to-date with 'gerrit/13.18'.
> > $ git describe
> > 13.18.4
>
>
> > $
> >
> > We have to create the minor release branch (13.18) and do the work there
> so
> > that patch releases (13.18.4) are based on the minor release branch, not
> > the major branch.
>
> Those branches are likewise short-lived branches (at least with respect
> to the number of commits). Real work is done on master, 13, 15 and such.
> But when I'm on such a branch, I can't ask git on which branch I am (not
> to mention: at which stage in it).
>

 I _think_ I understand now.

>
> For instance: maybe whenever you tag a new release branch (e.g. 13.18),
> tag the split point as something like "13.18.base" or "base.13.18"?
>

Well, that's easy enough.  Toss us an issue for it.


>
> But maybe it's just me and branches 13 and 15 are not widely used (for
> master it is irrelevant anyway).
>
> --
>Tzafrir Cohen
> +972-50-7952406   mailto:tzafrir.co...@xorcom.com
> http://www.xorcom.com
>
> --
> _
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>http://lists.digium.com/mailman/listinfo/asterisk-dev
>



-- 
George Joseph
Digium, Inc. | Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - US
Check us out at: www.digium.com & www.asterisk.org
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] tags on the main branches [was: Re: Minor Release Branches]

[Tzafrir Cohen]

On Wed, Dec 20, 2017 at 07:50:03AM -0700, George Joseph wrote:
> On Wed, Dec 20, 2017 at 2:44 AM, Tzafrir Cohen 
> wrote:
> 
> > Off-topic:
> >
> > On Tue, Dec 19, 2017 at 01:50:03PM -0700, George Joseph wrote:
> >
> > > Thankfully we tag EVERYTHING! :)
> >
> > asterisk(13)$ git describe
> > 13.15.0-rc1-908-ge31e3b581b
> >
> > asterisk(14)$ git describe
> > fatal: No tags can describe 'fb18797ae09a685ec71101499fb1c1c606b16397'.
> > Try --always, or create some tags.
> >
> > asterisk(15)$ git describe
> > fatal: No tags can describe 'd312068ee93ff8ce97b464f3c2ff3304e15cb3fe'.
> > Try --always, or create some tags.
> >
> >
> > I wasted half an hour yesterday trying to find out why a build sis not
> > switch from master to 13, only to realize that the name of the git
> > branch in the version string is always "master".
> >
> > We tag everything. But only well after it was branched from the main
> >
> branch.
> >
> 
> I'm not following you.
> 
> We tag every release...
> 
> $ git checkout 13.18.4
> HEAD is now at f4644317b7... Update for 13.18.4
> $ git describe
> 13.18.4


> $ git checkout 13.18
> Switched to branch '13.18'
> Your branch is up-to-date with 'gerrit/13.18'.
> $ git describe
> 13.18.4


> $
> 
> We have to create the minor release branch (13.18) and do the work there so
> that patch releases (13.18.4) are based on the minor release branch, not
> the major branch.

Those branches are likewise short-lived branches (at least with respect
to the number of commits). Real work is done on master, 13, 15 and such.
But when I'm on such a branch, I can't ask git on which branch I am (not
to mention: at which stage in it).

For instance: maybe whenever you tag a new release branch (e.g. 13.18),
tag the split point as something like "13.18.base" or "base.13.18"?

But maybe it's just me and branches 13 and 15 are not widely used (for
master it is irrelevant anyway).

-- 
   Tzafrir Cohen
+972-50-7952406   mailto:tzafrir.co...@xorcom.com
http://www.xorcom.com

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] tags on the main branches [was: Re: Minor Release Branches]

[George Joseph]

On Wed, Dec 20, 2017 at 2:44 AM, Tzafrir Cohen 
wrote:

> Off-topic:
>
> On Tue, Dec 19, 2017 at 01:50:03PM -0700, George Joseph wrote:
>
> > Thankfully we tag EVERYTHING! :)
>
> asterisk(13)$ git describe
> 13.15.0-rc1-908-ge31e3b581b
>
> asterisk(14)$ git describe
> fatal: No tags can describe 'fb18797ae09a685ec71101499fb1c1c606b16397'.
> Try --always, or create some tags.
>
> asterisk(15)$ git describe
> fatal: No tags can describe 'd312068ee93ff8ce97b464f3c2ff3304e15cb3fe'.
> Try --always, or create some tags.
>
>
> I wasted half an hour yesterday trying to find out why a build sis not
> switch from master to 13, only to realize that the name of the git
> branch in the version string is always "master".
>
> We tag everything. But only well after it was branched from the main
>
branch.
>

I'm not following you.

We tag every release...

$ git checkout 13.18.4
HEAD is now at f4644317b7... Update for 13.18.4
$ git describe
13.18.4
$ commit f4644317b7dd1963c92dc13295027cdfbb4fbc5e (HEAD, tag: 13.18.4,
gerrit/13.18, 13.18)
Author: George Joseph 
Date:   Wed Dec 13 09:33:48 2017 -0500

Update for 13.18.4

commit 8052b5d76ed5d2b16436335c67877c1a09012c3c
$

The commit that's tagged is the one that has all the housekeeping
(ChangeLog, summaries, .version) for the release so that commit will never
be in the main branches.  It will be in the release branches however...

$ git checkout 13.18
Switched to branch '13.18'
Your branch is up-to-date with 'gerrit/13.18'.
$ git describe
13.18.4
$

We have to create the minor release branch (13.18) and do the work there so
that patch releases (13.18.4) are based on the minor release branch, not
the major branch.














>
> --
>Tzafrir Cohen
> +972-50-7952406   mailto:tzafrir.co...@xorcom.com
> http://www.xorcom.com
>
> --
> _
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>http://lists.digium.com/mailman/listinfo/asterisk-dev
>



-- 
George Joseph
Digium, Inc. | Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - US
Check us out at: www.digium.com & www.asterisk.org
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

[asterisk-dev] tags on the main branches [was: Re: Minor Release Branches]

[Tzafrir Cohen]

Off-topic:

On Tue, Dec 19, 2017 at 01:50:03PM -0700, George Joseph wrote:

> Thankfully we tag EVERYTHING! :)

asterisk(13)$ git describe 
13.15.0-rc1-908-ge31e3b581b

asterisk(14)$ git describe 
fatal: No tags can describe 'fb18797ae09a685ec71101499fb1c1c606b16397'.
Try --always, or create some tags.

asterisk(15)$ git describe 
fatal: No tags can describe 'd312068ee93ff8ce97b464f3c2ff3304e15cb3fe'.
Try --always, or create some tags.


I wasted half an hour yesterday trying to find out why a build sis not
switch from master to 13, only to realize that the name of the git
branch in the version string is always "master".

We tag everything. But only well after it was branched from the main
branch.

-- 
   Tzafrir Cohen
+972-50-7952406   mailto:tzafrir.co...@xorcom.com
http://www.xorcom.com

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev