kicad-developers team mailing list archive

[Chris Pavlina <pavlina.chris@xxxxxxxxx>]

Pushed. :)

On Fri, Sep 09, 2016 at 02:08:52PM -0400, Wayne Stambaugh wrote:
> 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.  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