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
