On Thu, Oct 8, 2015 at 8:36 AM, Simon Slavin wrote:
>
> On 8 Oct 2015, at 2:38pm, Richard Hipp wrote:
>
> > If accepted, the new policy will cause the next release to be 3.9.0
> > instead of 3.8.12. And the second number in the version will be
> > increased much more aggressively in future rele
2015-10-08 15:38 GMT+02:00 Richard Hipp :
> Several users have proposed that SQLite adopt a new version numbering
> scheme. The proposed change is currently uploaded on the "draft"
> website:
>
> https://www.sqlite.org/draft/versionnumbers.html
> https://www.sqlite.org/draft/releaselog/3_9
Jan, I see no merit to your proposal and plenty of downsides. SQLite's current
release schedule works quite well, there is no good reason to formally do
feature releases just twice a year, especially with that terrible terrible 9x
kludge. There's also no reason to pander to guesses about what
On 10/8/15, Darren Duncan wrote:
>
> 2. If two successive versions have an overlapping but not equal API and
> file format, meaning that a subset of data files but not all of such readable
> or
> writeable by one version is readable and writeable by the other, or that a
> subset of code but not
On 2015-10-08 6:03 PM, Richard Hipp wrote:
> On 10/8/15, Darren Duncan wrote:
>>
>> 2. If two successive versions have an overlapping but not equal API and
>> file format, meaning that a subset of data files but not all of such
>> readable or
>> writeable by one version is readable and writeable
Richard, I agree with your proposal herein stated, at least as I understand it.
I would propose that with a W.X.Y semantic version scheme, which I think is
what
you said, the parts mean essentially [disjoint.overlapping.equal], by which I
mean:
1. If two successive versions have a disjoint AP
.org>
> Subject: Re: [sqlite] Proposed new version numbering scheme for SQLite -
> Feedback requested
>
>
> On 8 Oct 2015, at 2:38pm, Richard Hipp wrote:
>
> > If accepted, the new policy will cause the next release to be 3.9.0
> > instead of 3.8.12. And the se
On 8 Oct 2015, at 2:38pm, Richard Hipp wrote:
> If accepted, the new policy will cause the next release to be 3.9.0
> instead of 3.8.12. And the second number in the version will be
> increased much more aggressively in future releases.
I approve of this particular release changing the Y value
On Thu, Oct 8, 2015 at 8:36 AM, Simon Slavin wrote:
>
> On 8 Oct 2015, at 2:38pm, Richard Hipp wrote:
>
> > If accepted, the new policy will cause the next release to be 3.9.0
> > instead of 3.8.12. And the second number in the version will be
> > increased much more aggressively in future rele
Several users have proposed that SQLite adopt a new version numbering
scheme. The proposed change is currently uploaded on the "draft"
website:
https://www.sqlite.org/draft/versionnumbers.html
https://www.sqlite.org/draft/releaselog/3_9_0.html
https://www.sqlite.org/draft/
If accepte
10 matches
Mail list logo