kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxx>]

@Nick.  What do think?  Makes sense to me to be able to distinguish
between official github mirror version and someone's local branch
changes.  This should not really happen with our nightly builds but that
doesn't prevent someone from doing this themselves with their own
builds.  This could be useful developer information if someone files a
bug report against a locally modified branch.  It could potentially save
developers time trying to pin down a bug that was created by local
branch changes.


On 9/11/2015 4:16 AM, Joseph Chen wrote:
> Hi Nick,
> 
> I very much like the true BZR version number that is produced by your
> script when compiling from the git mirror source.  This is very helpful
> when tracking the matching version of KiCAD from the bzr repo.
> 
> In the new way that I proposed for producing BZR version number, I
> pretty much borrowed the tick that is being used by Linux kernel: when a
> cloned local source tree is the same as the up stream's, the version
> string is like "3.2.1" as the official release number. But,  after some
> changes, the version string becomes "3.2.1-dirty-f6cd3", where "f6cd3"
> is the short hash of the local head.  This means that the version is not
> official release any more.
> 
> I hope this trivial patch can help in distinguish a true BZR version
> from those with local modifications.
> 
> --Joe
> 
> On 09/10/2015 05:54 PM, Nick Østergaard wrote:
>> Hi
>>
>> This is a matter of what we really want. When I wrote the logic at
>> first, my goal was just to make sure to generate a bzr version that
>> matches how the bzr cmake module did it, when building with an
>> unmodified tree. I think my version complies to that; that is not
>> taking care about weather or not you are on a local banch.
>>
>> I have not tested this patch, but it looks alright to me. I am fine
>> with extending it with this detail, although one could argue that
>> holding the bzr rev as is, is not entirely correct, but if you get the
>> complete version string you can deduce that there are changes. For
>> example as you state the HEAD for the bzr number, you could also state
>> the HEAD and origin/HEAD for the bzr number, like, BZR 1234-1236 if
>> you have two commits in difference from the product branch.
>>
>> I am ok with either, but some people might find it odd as is.
>>
>> But I think the patch is not complete, the auxilarry variables should
>> probably be of the last local commit. That is the variables like
>> _git_LAST_COMITTER and _git_LONG_HASH. (Maybe they are ok, hard to see
>> properly in the patch only, I did not apply it.)
>>
>> Nick
>>
>> 2015-09-10 17:15 GMT+02:00 Wayne Stambaugh <stambaughw@xxxxxxxxx>:
>>> @Nick, have you had a chance to look at this patch?  Since you wrote
>>> this I thought you should have some input.  I'm not sure if this the
>>> correct behavior when using git to generate the KiCad version string.
>>> It seems as though Joseph is correct.  Would you please take a look at
>>> it when you get a chance and let me know if it should be committed.
>>>
>>> Thanks,
>>>
>>> Wayne
>>>
>>> On 8/30/2015 4:24 PM, Joseph Chen wrote:
>>>> Please review and apply the attached patch file of
>>>> CreateGitVersion.cmake.
>>>>
>>>> *Issue to be fixed: a False BZR version number**
>>>> *
>>>> The details:
>>>> After cloning the repo of git-source-mirror, and working in my own
>>>> local
>>>> branch, and committing a X times, the BZR version-number that is
>>>> generated by file CreateGitVersion.cmake is incremented by X number.
>>>> This is a mismatch of the true BZR number.
>>>>
>>>> The tests:
>>>> _Before applying this patch_:
>>>>
>>>> The command "Copy Version Info" built from the origin "master" branch
>>>> displays the following:
>>>>          Version: (2015-08-30 *BZR 6134, Git 4e94d52*)-product
>>>> release build
>>>> which is correct.
>>>>
>>>> _However_, after creating a local branch based off the "master" branch,
>>>> and having committed 2 more times in the local branch, the command
>>>> "Copy
>>>> Version Info" built from the local branch displays the following false
>>>> BZR number:
>>>>          Version: (2015-08-30 *BZR 6136, Git edfb32e*)-product
>>>> release build
>>>> which is _false_, because at the time the official BZR number is only
>>>> *6134*.
>>>>
>>>>
>>>> _After applying this_patch_:
>>>> The command "Copy Version Info" built from the "master" branch displays
>>>> the following:
>>>>           Version: (2015-08-30 *BZR 6134, Git 4e94d52*)-product
>>>> release build
>>>> which is still correct.
>>>>
>>>> Now, the command "Copy Version Info" built from the local branch that
>>>> has 2 extra commits displayes the following:
>>>>          Version: (2015-08-30 *BZR 6134, Git 4e94d52-ede23f9*)-product
>>>> release build
>>>> which is still correct with a _true_ *BZR 6134*, plus it has an *added
>>>> GIT short hash* from the local branch HEAD.
>>>>
>>>> This added GIT short hash tells us that the running version is built
>>>> based off a true BZR 6134, plus some local modifications up to GIT
>>>> short
>>>> hash of *ede23f9.*
>>>>
>>>> --Joe
>>>>
>>>>
>>>> _______________________________________________
>>>> Mailing list: https://launchpad.net/~kicad-developers
>>>> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>>> More help   : https://help.launchpad.net/ListHelp
>>>>
>>> _______________________________________________
>>> Mailing list: https://launchpad.net/~kicad-developers
>>> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>> More help   : https://help.launchpad.net/ListHelp
>