kicad-developers team mailing list archive

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

2016-11-28 0:01 GMT+01:00 Joseph Chen <joseph.chen59@xxxxxxxxx>:
> As I see it, KiCAD now is using a backward schema in versioning, after
> converted to GIT repo.
>
> As most of you guys already know it, GIT has a command "git describe
> --dirty" for outputting a precise trackable version info.  So regardless of
> branches, the version string should be set by the output of this GIT
> command.  (I was a seasonal Linux kernel driver contributor over 10 years
> ago and Linux kernel has been using this way for versioning).
>
> Here is an example:
> 1. Withi my current running Kicad, cliking "Help-->About Kicad",  it
> produces
>      "Version: (2016-11-10 revision 3184295)-master, release build"
> Which is not trackable at all.  If I filed a bug report with this version
> info, you would definitely be unable to pinpoint to a exact source set in
> the repo.
>
> 2.  In contrast, invoking the GIT command in the source repo produces:
> jchen@thermaltake ~/git-kicad/kicad (master)
> $ git describe --dirty
> 4.0.0-rc2-1622-g3184295
> jchen@thermaltake ~/git-kicad/kicad (master)
>
> As you can see, it says the current version has been committed "1622" times
> after tag "4.0.0.rc2", and the git commit SHA1 signature is "3184295".
>
> Hope this makes sense to you guys.
>
> --Joe Chen
>

That is all fine, but that is not the real issue here. The issue is
how to get a version from the tarball release. One could argue that we
should just stop using tarballs and packagers should use git directly.
That could posisbly work, but the problem may still arise if packagers
use the repository web viewer tool to get a tarball from the tag. Then
the question still becomes; how do we make sure there are a sane
version when there is no git to help us.

>
>
> On 11/27/2016 10:15 AM, Wayne Stambaugh wrote:
>>
>> On 11/26/2016 3:22 AM, Nick Østergaard wrote:
>>>
>>> 2016-11-25 15:51 GMT+01:00 Wayne Stambaugh <stambaughw@xxxxxxxxx>:
>>>>
>>>> Correct.  Do we really need override the entire version string?  I've
>>>> been working under the assumption that we should be setting the base
>>>> version and users can use the optional variables to append to the base
>>>> version.  If we allow users to set the base version to anything, that
>>>> would open us up to version conflicts and/or errors (which has happened
>>>> in the past).
>>>
>>> How are you going to handle it with KiCadVersion.cmake? As is now,
>>> changing it will be a total override. Wouldn't it be better for it to
>>> behave differently if it was a git repo, meaning to use the string if
>>> the latest commit is that same tag. Otherwise you can still end up
>>> with many 4.0.5 versions that are really not the same commit.
>>
>> I plan on setting the version in KiCadVersion.cmake for stable tagged
>> releases.  I think it makes sense to set it back to "no-vcs-found" in
>> the stable branch until the next tagged stable release.  I will always
>> be set to "no-vcs-found" in the master branch since we want the version
>> string generated by git for nightly builds.
>>
>>>> I'm open to this idea but I want to make sure it's
>>>> necessary before I make any changes.  For stable releases, KICAD_VERSION
>>>> will be set to the version number so that should always be part of the
>>>> version string for stable releases.  This will work with source archives
>>>> and a git clone of the release tag.  In all other cases, the git
>>>> determines the base version string.
>>>
>>> This is not how it works on the master branch now. The
>>> KiCadVersion.cmake overrides in all cases.
>>>
>> KiCadVersion.cmake takes precedence when is configured for anything
>> other than "no-vcs-found".  The reason that I did it this way so that
>> the project has control over the base version string.  I don't know if
>> it's a good idea to allow anyone to set the base version string to
>> anything they want.  Is that something package devs typically do?
>>
>> _______________________________________________
>> 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