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 either the output of `git describe --dirty`
or "5.0.0-rc2-unknown".
On 3/13/2018 3:56 PM, hauptmech wrote:
> 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
> development sequence). It's just a number.
>
> On 14/03/18 05:49, Wayne Stambaugh wrote:
>> 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 pretty sure no matter what we do, someone will be confused.
>> I'm not really interested in making the cmake version string code any
>> more complicated so unless there are some options to `git describe` that
>> would make things clearer, I'm going to stick with the current code.
>>
>> On 3/13/2018 12:18 PM, Carsten Schoenert wrote:
>>> Am 13.03.2018 um 17:05 schrieb Eeli Kaikkonen:
>>>> 2018-03-13 17:44 GMT+02:00 Jon Evans <j...@craftyjon.com>:
>>>>
>>>>> 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 it, or at least tries to make it a
>>>>> lot more
>>>>> obvious that it isn't a RC version despite having those letters in the
>>>>> string.
>>>>>
>>>> In a project where I took part in we solved a similar problem by using
>>>> {previous-tagged-version-number}+{version-control-reference}, for
>>>> example
>>>> 5.0RC1+gitXXXXX. We felt the plus sign is less ambiguous.
>>> That would be the correct way and done by a lot of projects.
>>>
>>> The now additional tag -rc2-dev makes it more difficult for
>>> distributions to determine if a new version is available.
>>>
>>> -rc2* is greater as -rc1 and I'd need to tune the watch file again in
>>> Debian we use (and it's already a bit more complicated due the dfsg + rc
>>> part). The added tag -rc2-dev solves nothing and shouldn't be used in
>>> future situations.
>>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help : https://help.launchpad.net/ListHelp
>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help : https://help.launchpad.net/ListHelp
_______________________________________________
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help : https://help.launchpad.net/ListHelp
