Hi On Wed, Mar 8, 2017 at 12:20 PM Gerd Hoffmann <kra...@redhat.com> wrote:
> Hi, > > > libvirt suffered similar lack of clarity around when to bump major > version > > number as opposed to minor version. To address this we recently adopted > the > > rule[1] that major version number changes have no relation to features. > The > > major number is simply incremented at the start of each calendar year. > > I like the idea of time-based version numbering. Changing the plan for > 2.9 still is probably a bad idea given we have a 2.9 machine type > already etc. > > But we can start changing things afterwards. So we could start with 3.x > after 2.9, and bump the major for the first release each year > (libvirt-style). Or we could use the year as major number and jump > straight to 17.x (mesa-style). > > > From the POV of libvirt, I don't think saying that .0 releases have > > incompatible changes is particularly useful in itself. What *is* useful > > is to have a clear rule around a deprecation cycle. ie, a rule that says > > a feature will be marked deprecated for 3 releases or 12 months, before > it > > is permitted to be removed/changed. If that were followed, there is no > > need to batch up such changes in a .0 release IMHO. > > Yes, it's probably a good idea to deprecate things first. When going > with the 12 months rule it could be useful to batch things and do a > yearly "spring cleaning" when the major is bumped. > > What about deprecating GTK 2.0 ? SDL (1.2 or all?) I suspect there are also a number of arm boards that are not regularly tested and could be drop, who could tell? -- Marc-André Lureau
