[sqlite] Proposed new version numbering scheme for SQLite - Feedback requested

2015-10-09 Thread Klaas V
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

[sqlite] Proposed new version numbering scheme for SQLite - Feedback requested

2015-10-09 Thread Jan Nijtmans
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 >

[sqlite] Proposed new version numbering scheme for SQLite - Feedback requested

2015-10-09 Thread Darren Duncan
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

[sqlite] Proposed new version numbering scheme for SQLite - Feedback requested

2015-10-08 Thread Richard Hipp
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

[sqlite] Proposed new version numbering scheme for SQLite - Feedback requested

2015-10-08 Thread Darren Duncan
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

[sqlite] Proposed new version numbering scheme for SQLite - Feedback requested

2015-10-08 Thread Darren Duncan
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

[sqlite] Proposed new version numbering scheme for SQLite - Feedback requested

2015-10-08 Thread Bert Huijben
.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

[sqlite] Proposed new version numbering scheme for SQLite - Feedback requested

2015-10-08 Thread Simon Slavin
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

[sqlite] Proposed new version numbering scheme for SQLite - Feedback requested

2015-10-08 Thread Scott Robison
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

[sqlite] Proposed new version numbering scheme for SQLite - Feedback requested

2015-10-08 Thread 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_0.html https://www.sqlite.org/draft/ If