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 Linux distribution managers think about project stability, their knowing version numbers in advance has no value, and they can be explicitly told or read SQLite announcements to know what is stable or not. In reality, distro managers will cut releases on their own schedule, and use whatever's the newest SQLite at the time, and SQLite itself should be released on its own schedule. Also, while some projects like 6-month feature releases, that is far from a concensus. I know a bunch that like annual releases, Postgres and Perl for example, which work well. -- Darren Duncan
On 2015-10-09 1:51 AM, Jan Nijtmans wrote: > 2015-10-08 15:38 GMT+02:00 Richard Hipp <drh at sqlite.org>: >> 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 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. >> >> Your feedback on the proposed policy change is appreciated. We will >> delay the next release until there is a semblance of consensus on the >> new policy. > > Reading the other reactions, there seems to be consensus on > the next release being 3.9.0, not 3.8.12. So I hope the delay > will not be that much. Details on the exact definition of > X/Y/Z is not that important to me, but since you ask.... > > One idea could be to lower the number of 'major' releases > to about twice a year. This means that Linux distributions, > like Ubuntu and Fedora can know in advance which > SQLite release will match their release. > Ubuntu: <https://wiki.ubuntu.com/Releases> > Fedora: <https://fedoraproject.org/wiki/Fedora_Release_Life_Cycle> > (everyone seems to think twice a year is optimal, don't know why) > > If there is a desire for new features to be released in between, > this could be done by intermediate 9x releases, at will. e.g.: > > 3.9.0 - okt 2015 > 3.9.1 - nov 2015 (performance improvement/bugfix only) > 3.9.90 - dec 2015 (well-tested, new feature 1 added + bugfixes) > 3.9.2 - jan 2016 (bugfixes only, without feature 1) > 3.9.91 - feb 2016 (well-tested, new feature 2 added + bugfixes) > 3.10.0 - april 2016 (well-tested, contains feature 1 + 2 + more) > 3.11.0 - okt 2016 > ........ > 3.79.0 - okt 2050 > ........ > 3.99.0 - okt 2060 ;-) > > Advantage: > 1) less 'major' releases gives the signal to managers that apparently > the software is more stable (even though we know that SQLite's > trunk is very stable always). > 2) No limitation when/what to release. It can be fully driven by the > desire of SQLite consortium members: Whenever a new feature > is implemented and ready to be released, it can always be done > in an official 3.x.9y release, outside of the half-yearly schedule. > 3) No need to adapt the tarball filename. > 4) All 3.x.0 and 3.x.9y releases can be done directly from trunk, > as done now. 3.x.[1-9]+ will generally be done from a branch. > Disadvantage: > 1) 3.x.9y releases will give the signal to managers being less > stable than 3.x,y releases. We know that's not necessarily > true, but that's the price for advantage 1) > > Just my 2c. > > Regards, > Jan Nijtmans
