kicad-developers team mailing list archive

[Nick Østergaard <oe.nick@xxxxxxxxx>]

Hi Joseph

Yes, I agree with you and understand the reasoning. I was just not
able to see the file patched and only reviewed the patch file itself.
I have now tried to apply it.

Some comments:

1. The line just before "# Get origin Repo HEAD" should probably be an
empth line to match the rest of the execute_process'.

2. We also create a long hash variable, although it is not used
anywhere else than for the cmake messaging, but we should probably me
explicit on which exact has that is. As is not that is a _LOCAL hash.
This to match the short hash.

If you adjust those two points, I think it is fine to merge it.

2015-09-11 10:16 GMT+02:00 Joseph Chen <joseph.chen59@xxxxxxxxx>:
> 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
>
>