Here is what I will do that should work. I will leave the current
version tag and version string as is until rc2 is released. From there
on I will only update the version string in KiCadVersion.cmake to
5.0.0-rc2-unknown in the next commit after the tag. This way the
version string will will be
I would not change anything. As long as your version increments as
documented, there is no problem. But if you change that by jumping
backwards, you create an exception that has the opportunity to bite people.
So what if you skipped RC1 in your version string (and therefore in your
To prevent version issues for packagers, I will remove the -rc2 tag from
the source repo and change the default (when git is not found) version
string to 5.0.0-rc1-unknown to indicate that the version is somewhere
between rc1 and rc2. I don't know that this makes things any clearer or
not but I'm
Am 13.03.2018 um 17:05 schrieb Eeli Kaikkonen:
> 2018-03-13 17:44 GMT+02:00 Jon Evans :
>
>> I know what the G means, just wish git describe had an option to disable
>> it, since it makes copy/paste more tedious.
>>
>> I think if we had left the tag at rc1, then we'd just have
2018-03-13 17:44 GMT+02:00 Jon Evans :
> I know what the G means, just wish git describe had an option to disable
> it, since it makes copy/paste more tedious.
>
> I think if we had left the tag at rc1, then we'd just have users thinking
> they had rc1 when they really have a
I know what the G means, just wish git describe had an option to disable
it, since it makes copy/paste more tedious.
I think if we had left the tag at rc1, then we'd just have users thinking
they had rc1 when they really have a newer nightly. Better to make a new
tag that doesn't include rcN in
I think it would have been better if the commit after 5.0.0-rc1 was not
tagged 5.0.0-rc2-dev. Then the git describe would make more sense. It would
indicate that it was based on the 5.0.0-rc1 with additional commits and its
hash.
The g stands for git according to the man page.
On 3/12/2018 10:40 AM, Steven A. Falco wrote:
> On 03/12/2018 10:23 AM, Jon Evans wrote:
>> I have seen multiple users who run nightlies think they have RC2 because
>> they read "5.0.0-rc2" and stop reading after that :-)
>> Maybe we should switch the tag back to "5.0-dev" between RC releases?
>>
On 03/12/2018 10:23 AM, Jon Evans wrote:
> I have seen multiple users who run nightlies think they have RC2 because they
> read "5.0.0-rc2" and stop reading after that :-)
> Maybe we should switch the tag back to "5.0-dev" between RC releases?
> I think all of us developers are going to look up
On 3/12/2018 10:23 AM, Jon Evans wrote:
> I have seen multiple users who run nightlies think they have RC2 because
> they read "5.0.0-rc2" and stop reading after that :-)
> Maybe we should switch the tag back to "5.0-dev" between RC releases?
> I think all of us developers are going to look up the
I have seen multiple users who run nightlies think they have RC2 because
they read "5.0.0-rc2" and stop reading after that :-)
Maybe we should switch the tag back to "5.0-dev" between RC releases?
I think all of us developers are going to look up the git hash anyway to
know exactly when a given
The version string should look like 5.0.0-rc2-dev-176-g53c9143b6 or
5.0.0-rc2-dev. The latter only happens if KiCad is built from a source
archive or git isn't available to generate the full version sting.
Wayne
On 3/12/2018 10:02 AM, Rene Pöschl wrote:
> Hello
>
> It seems at least some
Yes, the version string was bumped to 5.0.0-rc2-dev
Maybe it would be less confusing to have it be "5.0.0-pre-rc2-dev" ?
On Mon, Mar 12, 2018 at 10:02 AM, Rene Pöschl wrote:
> Hello
>
> It seems at least some packages of current nightlies report themselves as
> version
13 matches
Mail list logo