[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH 0/4] yacc.c: provide the Bison version as an integral macro
From: |
Akim Demaille |
Subject: |
Re: [PATCH 0/4] yacc.c: provide the Bison version as an integral macro |
Date: |
Sat, 21 Nov 2020 14:08:11 +0100 |
Hi Uxio,
> Le 19 nov. 2020 à 18:55, uxio prego <uxio.prego@gmail.com> a écrit :
>
> Hi,
>
>> On 11 Nov 2020, at 09:05, Akim Demaille <akim.demaille@gmail.com> wrote:
>>
>> I used a scale of 100, which should not be a problem. We could use a
>> scale of 1000
>
> Do you still use a count starting in 90 for release candidates?
Yes, I usually do.
> How safe is a limit of ten release candidates?
Given the history, I think it is safe enough:
$ git tag -l | fgrep .9
v2.6.90
v2.7.90
v2.7.91
v3.1.90
v3.1.91
v3.2.90
v3.2.91
v3.3.90
v3.3.91
v3.4.90
v3.4.91
v3.4.92
v3.5.90
v3.5.91
v3.5.92
v3.5.93
v3.5.94
v3.6.90
v3.6.91
v3.6.92
v3.6.93
>> , or even something not regular as Boost does (107400 is
>> 1.74).
>
> Hm.
>
> The obvious: there is no ‘1.74’, there is ‘1.74.0’.
Yeah, ok.
> The sneaky: there is a ‘1.65.1’ listed.
>
> https://github.com/boostorg/config/commit/4239074552cb233c09f344d5b76c80b8c22f22c8
Which is indeed `#define BOOST_VERSION 106501`. I'm not sure I saw
what you wanted me to see here.
Cheers!
- [PATCH 0/4] yacc.c: provide the Bison version as an integral macro, Akim Demaille, 2020/11/11
- [PATCH 1/4] %require: accept version numbers with three parts ("3.7.4"), Akim Demaille, 2020/11/11
- [PATCH 2/4] style: make conversion of version string to int public, Akim Demaille, 2020/11/11
- [PATCH 3/4] regen, Akim Demaille, 2020/11/11
- [PATCH 4/4] yacc.c: provide the Bison version as an integral macro, Akim Demaille, 2020/11/11
- Re: [PATCH 0/4] yacc.c: provide the Bison version as an integral macro, uxio prego, 2020/11/19
- Re: [PATCH 0/4] yacc.c: provide the Bison version as an integral macro,
Akim Demaille <=