On Wed, Oct 16, 2019 at 10:02:27AM +0200, David Demelier wrote:
> Le 09/10/2019 à 03:26, Gregory Szorc a écrit :
> > Our new versioning scheme will be .[M]M.N. e.g. 2020.5.0 or
> > 2020.10.1. This scheme consists of the 4 digit year, a 1-2 digit month,
> > and a monotonically increasing point r
Le 16/10/2019 à 18:17, Gregory Szorc a écrit :
Mercurial has not guaranteed internal API stability in recent memory.
Attempting to tie versions to internal APIs does not make sense.
I don't buy it. Because we never had means will never have? For example,
the Redmine project had several trouble
On Wed, Oct 16, 2019 at 1:09 AM David Demelier wrote:
> Le 09/10/2019 à 03:26, Gregory Szorc a écrit :
> > Our new versioning scheme will be .[M]M.N. e.g. 2020.5.0 or
> > 2020.10.1. This scheme consists of the 4 digit year, a 1-2 digit month,
> > and a monotonically increasing point release,
> On Oct 16, 2019, at 04:02, David Demelier wrote:
>
> I also don't understand why we keep creating releases at specific dates while
> not just release “once it's ready”.
We used to do that, long long ago (like...9 or 10 years ago). In practice it
meant we had trouble ever getting releases o
> On Oct 16, 2019, at 06:19, Anton Shestakov wrote:
>
>> Succinctly, we decided to adopt calendar versioning because Mercurial's
>> version numbers don't have much semantic meaning and may confuse users who
>> think the major version number changes imply breaking changes. Furthermore,
>> calend
> On Oct 15, 2019, at 14:47, André Sintzoff wrote:
>
> Le mer. 9 oct. 2019 à 03:30, Gregory Szorc a écrit :
>>
>> Our new versioning scheme will be .[M]M.N. e.g. 2020.5.0 or 2020.10.1.
>> This scheme consists of the 4 digit year, a 1-2 digit month, and a
>> monotonically increasing poin
On Tue, 8 Oct 2019 18:26:46 -0700
Gregory Szorc wrote:
> I referred to the releases by calendar date because at the 5.2 Sprint we
> decided to adopt calendar versioning starting with the first Mercurial
> release that is Python 3 only.
>
> Our new versioning scheme will be .[M]M.N. e.g. 2020
Le 09/10/2019 à 03:26, Gregory Szorc a écrit :
Our new versioning scheme will be .[M]M.N. e.g. 2020.5.0 or
2020.10.1. This scheme consists of the 4 digit year, a 1-2 digit month,
and a monotonically increasing point release, starting at 0. This scheme
is compatible with our existing version
Le mer. 9 oct. 2019 à 03:30, Gregory Szorc a écrit :
>
> Our new versioning scheme will be .[M]M.N. e.g. 2020.5.0 or 2020.10.1.
> This scheme consists of the 4 digit year, a 1-2 digit month, and a
> monotonically increasing point release, starting at 0. This scheme is
> compatible with our
At the Mercurial 5.2 Sprint last weekend, we made a number of decisions
regarding Python 3 and version numbers.
Our plan is to make Mercurial 5.2 (the next release planned for November 1)
stable on Python 3 on all major platforms. This entails Mercurial passing
as many tests as a Python 2.7 based
10 matches
Mail list logo
