kicad-developers team mailing list archive
-
kicad-developers team
-
Mailing list archive
-
Message #26177
Re: [PATCH] Update version string formatting after git migration
Probably not. We can always resurrect it from the dead should the need
be. I noticed the subversion stuff is still in there as well and we
haven't used svn since 2009. I'll remove it when I get a chance.
On 9/10/2016 4:47 PM, Simon Wells wrote:
> Is there any point in keeping around CreateBZRVersionHeader.cmake and
> FindBzr.cmake as i am not sure there is any bzr distribution methods
> left
>
> On Sun, Sep 11, 2016 at 12:21 AM, Nick Østergaard <oe.nick@xxxxxxxxx> wrote:
>> Den 09/09/2016 20.09 skrev "Wayne Stambaugh" <stambaughw@xxxxxxxxx>:
>>>
>>> Have we come to any consensus on this yet? I'm not sure the fake bzr
>>> revision numbers have any meaning. Git doesn't have any concept of
>>> linear commits so having a linear number will only make sense when
>>> building from the master repo. These numbers will not track upstream
>>> for anything built from a local repo that has deviated from the main
>>> repo.
>>
>> This was also the case for BZR :)
>>
>>> I'm leaning towards not using them. The hash is always accurate.
>>> If the is a commit hash that's not in the main repo, then it's obvious
>>> that the build is someone's custom commits. I'm OK with this patch as
>>> is. If there are no majo objects, @Chris go ahead and commit it.
>>>
>>> On 8/27/2016 2:49 PM, Mark Roszko wrote:
>>>> rev 1234 the same meaning as rev 67230ac, you have to look it up
>>>> regardless on git.
>>>>
>>>> On Sat, Aug 27, 2016 at 11:48 AM, jp charras <jp.charras@xxxxxxxxxx>
>>>> wrote:
>>>>> Le 27/08/2016 à 17:14, Chris Pavlina a écrit :
>>>>>> Now that we've migrated from bzr, there isn't much reason to keep
>>>>>> attaching a (now fake) bzr revision number to the version string.
>>>>>> Additionally, we can choose a sensible default branch name if one
>>>>>> isn't
>>>>>> specified on the cmake line, rather than "product". This patch
>>>>>> reformats
>>>>>> the version strings to:
>>>>>>
>>>>>> (2016-08-26 revision 67230ac)-master
>>>>>> | | |
>>>>>> | | custom branch name if set. Otherwise,
>>>>>> | | branch name, "HEAD" if not on a branch,
>>>>>> | | or "unknown" if no .git present
>>>>>> | |
>>>>>> | abbreviated commit hash, or no-git if no .git
>>>>>> | present
>>>>>> |
>>>>>> date of commit, or date of build if no .git present
>>>>>
>>>>> I find the bzr revision number useful to easily know the order of
>>>>> revisions.
>>>>> the name bzr is now a bit strange, so the version string could be:
>>>>>
>>>>> (2016-08-26 rev 1234 git 67230ac)-master
>>>>>
>>>>> (users, many times, just give a rev number, no the full version string,
>>>>> so in a bug or mail, rev
>>>>> 1234 has meaning, but revision 67230ac has no meaning, at least for
>>>>> me).
>>>>>
>>>>> --
>>>>> Jean-Pierre CHARRAS
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>
>>
>> _______________________________________________
>> 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
>>
Follow ups
References