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

Fri Dec 22 11:36:58 CST 2017

On Fri, Dec 22, 2017 at 9:50 AM, Corey Farrell <git at cfware.com> wrote:

> On 12/22/2017 10:22 AM, George Joseph wrote:
>
>
>
> On Thu, Dec 21, 2017 at 1:44 PM, Corey Farrell <git at cfware.com> 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 <git at cfware.com> 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 <tzafrir.cohen at xorcom.com
>>> > 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.cohen at 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.cohen at 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
>>>
>>
>>
>>
>> --
>> 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
>>
>
>
>
> --
> 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
>

-- 
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20171222/ca288f31/attachment-0001.html>