kicad-developers team mailing list archive
-
kicad-developers team
-
Mailing list archive
-
Message #26217
Re: [PATCH] Update version string formatting after git migration
Hey Wayne,
just in regards to e7e165d WriteVersionHeader.cmake still references
the removed bzr files if you want to remove that stuff as well
Simon
On Tue, Sep 13, 2016 at 12:52 AM, Wayne Stambaugh <stambaughw@xxxxxxxxx> wrote:
> 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