On Wednesday 12 of February 2014 06:43:15 Michele Calgaro wrote:
> Dear all,
> in etherpad 63 (http://trinity.etherpad.trinitydesktop.org/63) we had some
> discussions about switching to a fixed-time release cycle after R14.0.0 is
> out of the door. The end result of those discussions and the preliminary
> agreement of some developers is to use a 90-day release cycle (pending
> Tim's agreement too :) ).
>
> The idea is to issue a maintenance release R14.0.x every 3 months,
> containing bug fixes and minor improvements, and issue a minor release
> R14.y.0 every year containing bigger improvements. This will require bugs
> to be backported from the trunk to the R14.0.x branch for up to 9 months
> (which could become not that easy after several changes are done in the
> trunk) and would provide major improvements to the users only once a year.
> On the other hand, it may prove a more stable solution.
>
> An alternative scenario I have been tinkering for a while lately is one
> where every 3 months we ship whatever is in the trunk as the next release.
> In this case we do not need to backport any bug and users would be able to
> get major improvements up to 4 times each year. On the other hand we may
> introduce some degree of instability if a feature is not well tested before
> shipping it (but in any case that risk would exist also with the minor
> R14.y.0 releases of the first scenario), with the "fixing time" being the
> same (3 months in both scenarios).
>
> Given the limited amount of development resources that we have, I have come
> to like the second scenario the most, and I would like to hear the opinion
> of other developers as well. If we end up adopting the second scenario, I
> would also like to propose an alternative release version numbering schema:
> Ryy.x, where yy is the year number and x is a progressive release number
> within the yy year. So for example this year we would have R14.0, R14.1,
> R14.2 (and R14.3 is R14.0 is released before March 31). Then next year we
> would have R15.0, R15.1, R15.2 and R15.3 and so on.... Coincidentally, this
> year is 2014, so the year number matches the R14 release number too :)
>
> Also, a side-effect benefit would be that TDE would look more active to the
> general public with Ryy.x release numbers than R14.0.x release numbers,
> since the last would probably be thought of as "nothing major, just minor
> fixes".
>
> Looking forward for your opinions.
> Cheers
>   Michele
>

I dare to oppose it. 

In your proposal you want to avoid backporting => does not use branches. I 
believe that history in various projects, including our branch v3.5.13-sru, 
demonstrated that branches are very desirable. I am sure that regardless of 
our testing a new version, after new version will be released and ordinary 
users begin in their daily use, then users will find undiscovered bugs that 
need to be repaired quickly. When developing without branches, we were in a 
situation that we either could not release a new version, or we would have to 
release unfinished version or we had to keep slowing down of development. 
Neither of which I like.

Like David, who mentioned this in side reaction, I'm not a fan of the 
accelerated version numbering, regardless of the meaning of these numbers. Or 
even worse - meaning, that is not related to the code. I would say - Trinity 
is "conservative" desktop environment and so we use "conservative" version 
numbering. I am convinced that now used 14.x.y is good.

I assume that the highest micro/patch version number will most commonly 2, 3. 
Indeed, just as is the case of current stable branch 3.5.13.x. We will always 
try to finish as soon as possible "minor" versions. This will allow users to 
see that we take care of repairs for stable version (micro/patch versions), 
reasonably we move forward (minor versions), and at the same time the 
development continues conservative (modest in changes major versions).

Slavek
--