On 02/11/2014 11:43 PM, 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 :) ).
> 

Do not mistake any of the following as criticism, it isn't. This is an important
issue and it deserves careful consideration.

This may just be semantics, but if by 90-day release cycle, you mean creating
new tarballs for packagers to build from - fine.

A new minor version bump should only occur WHEN:

(1) A substantial new feature or capability is added/updated
      (e.g. Hal requirement dropped, etc...)

(2) The user interface substantially changes
      (then all users will walk away anyway)

(3) A collection of packages has undergone namechange
      (KDE -> TDE (or k->t) - avoid k->tde changes)

(4) The build system has been significantly altered/updated.

There are a plethora of examples where a "rapid fire", "rabbit pellet" release
cycle has completely ruined packages, desktops and distributions.

That being said, there is nothing wrong with maintenance releases of the form

  R14.0.0-[X+1]

So long as there are no build differences to the packagers required within
maintenance release. For example, upon R14.0.0-1 release the build requirements
for each of the packages are frozen. Through the next 50 (or whatever number)
maintenance releases (R14.0.0-1 -> R14.0.0-50) all packages will continue to
build in the same manner as they built with R14.0.0-1.

> 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.
> 

Agreed - no hard time requirements. If a new major feature/capability is ready
at 9 months or won't be ready for 18 months - making minor version number bumps
"mean something" is important - otherwise it is just another "rabbit pellet" drop.

Regardless of whether it is with a maintenance release or minor version bump, if
a significant fix occurs, backport as soon as testing/signoff occurs. Why wait?

> 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).
> 

NO. NO "rapid fire", "rabbit pellet" releases. This is a disaster waiting to
happen. That is the kde4, firefox, mandrake debacle all over again.

> 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 :)
> 

No - releases, minor, major bumps must "mean something". To tag releases to time
is meaningless it is just a coincidental moment in time without reference to
feature/capabilities, compatibilities or API.

You cannot do naming conventions like that without breaking packaging. While
many build system can "support (cludge)" non standard names, this can really
create havoc. Package/Release naming should always subscribe to:

  package-major.minor.micro-rel.arch.(compression

http://www.tldp.org/HOWTO/html_single/Software-Release-Practice-HOWTO/#naming

 package-major.minor[.micro]-qualifier.arch.(compression)

Good example: https://community.jboss.org/wiki/JBossProjectVersioning

Any reference to time is meaningless. See
http://programmers.stackexchange.com/questions/77637/yyyy-mm-dd-hhmm-vs-major-minor-revision,
comment 12:

 [YYYY].[MM].[DD].[hh][mm] has no meaning. It's just a coincidental binding
between a moment in time and a release

> 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
> 

From a technically competent desktop standpoint, no one should care if TDE "has
the appearance" of an active project, blah, blah, blah. The only thing that
matters is that it is technically current, well tested, stable and a desktop
that meets user expectations of providing all of that in a package that
maintains the traditional KDE3 look, feel, behavior and performance. Do that and
all the recognition a desktop of that caliber deserves will follow.

There is no faster way to destroy all of that hard work than to subscribe to
some meaningless rabbit pellet release cycle.

I think the suggestion of a 90 day maintenance release schedule is more than
sufficient for bug fixes, etc. I further think that before we began to talk
about minor version/version bumps we identify what the goals are for the next
minor version/version bump and then look at what a realistic time-frame is given
the manpower/skill available to get it done.

Looking at timetables before that is done is somewhat putting the proverbial
"cart" before the proverbial "horse"...

Don't mistake any of this as shooting the messenger, it's not, I commend all the
hard work and thought that is put in this direction. But, when asked for
opinion, this is the cumulative total you get on this issue from nearly
two-decades of Linux/OSS project involvement. TDE is a fantastic project and
desktop and should be managed going forward free from artificial timelines and
cycles that have been the death-nail of so many other good projects that have
come before it.

-- 
David C. Rankin, J.D.,P.E.