Message: previous - next
Month: February 2014

Re: [trinity-devel] Alternative release version numbering scheme proposal

From: "Darrell Anderson" <darrella@...>
Date: Wed, 12 Feb 2014 18:03:48 -0600
>Looking forward for your opinions.

To Michele:

I prefer the version system we have. The 90-day cycle will create 
the desired impression that Trinity is an active project. The long 
lapse caused by R14 has not helped us and is unusual, but hasn't 
killed us either --- we did have two maintenance releases.

To David:

We are not embracing a rapid release schedule. We are embracing a 
maintenance release schedule. The focus is a timely release of bug 
and security fixes. We do not have the resources for rapid release. 
We do not have the desire for rapid release. Trinity is not about 
using software as a playground to test ideas and brainstorms while 
users suffer. Trinity is all about retaining a traditional desktop 
interface. The types of new features we introduce conform to that 
project goal, which means we should never see a feature that breaks 

I am not in favor of Yet Another Number in the Version scheme. 
Three numbers is enough. I'll scream and shout for anything longer 
than tree.

I don't mind the R14 version scheme. I was not in favor of using and as versions. Those versions should have been 
3.5.14 and 3.5.15. Or, because of ABI breakage, 3.6 and 3.6.1. What 
is done is done. Moving forward we need the new version scheme to 
form our own identity. We discussed all of this long ago, even 
before you departed for many months.

The new version scheme is explained in the release notes. Open the 
help handbook, select the "Welcome to TDE" handbook, and select the 
Release Notes link.

I won't resist dropping the "R" from the version number. I'm fine 
with R14.0.0 or 14.0.0.

Soap box time:


The current version scheme is explained in tdeversion.h:


Initial release is always R<ABI VERSION>.0.0.

BUG AND SECURITY PATCH LEVEL is always updated with a point release.

FEATURE REVISION is updated when new features are introduced or 
features are significantly updated.

A FEATURE REVISION release does NOT include ABI changes.

A new FEATURE REVISION level always resets the BUG AND SECURITY 

A new ABI version resets both the FEATURE REVISION and BUG AND 


The big difference between current practices and post R14.0.0? We 
have to plan and to discipline ourselves. We have not done that at 
all during the R14 cycle. We just push and build.

Considering the way things have been done in the past, our current 
version scheme will always requires a main branch.

We are not finished with package and library renaming. More to come.

ABI/API breakage seems to occur frequently enough. Or, did 
frequently enough at one time. Usually unannounced. Future ABI/API 
breakage will have to be planned. Such patches will have to sit and 
wait until all other plans are finished and everybody is ready to 

Throughout the R14 cycle, we have not adhered to this version 
scheme. We have been regularly throwing darts and changing 
everything. After R14.0.0 we will have to discipline ourselves.


From a public awareness perspective, and I emphasize public 
awareness perspective, we're not dead yet as a project, but the R14 
cycle has been a slow and painful journey toward death for Trinity.

I want to emphasize and defend that we need a maintenance release 
cycle. We need to get back into the public eye. The R14 cycle has 
been grueling. Many users have all but forgotten Trinity. That is 
not good for us. Better awareness in the free/libre community means 
more users, more eyes, hopefully more people helping patch and 
improve Trinity.

We have been super cautious about releasing R14. I believe we will 
be rewarded with good reviews.

We need to motivate ourselves with keeping users happy. We do that 
with a maintenance release cycle. They have not been seeing Trinity 
much in the news the past 18 months. They are not seeing bug fixes. 
Is Trinity dead? A maintenance release cycle stifles such questions.

The Xfce project is a good example. They strictly use the "release 
when ready" strategy. Their last release announcement on their web 
site is getting close to two years old. Not comforting to users.

I appreciate Michele's long thoughts about the challenges we face. 
At the moment I remain open but I am not convinced to release the 
main trunk. Why?

* Our commit history is evidence for not doing that.

* We have no quality control program.

* We have no cmake conversion audit program.

* We have no mechanism to ensure i18n files are updated 
concurrently with parent modules (within the limitations of 

* We have no program to ensure help handbooks are updated timely, 
which includes i18n too.

* We tend to push patches that "work for me" but occasionally do 
not work for others (and all of us have pushed such patches, 
including me).

That is, releasing from the main trunk will slowly hurt the project 
to the point that the only users will be the developers.

I appreciate the energy required to maintain multiple branches. But 
unlike LO, we will only maintain two active branches. When the 
R14.0.1 tarballs are released we stop supporting R14.0.1 and that 
branch is frozen, perhaps even deleted after the tarballs are 
released. We then create the R14.0.2 or R14.1.0 branch. Or, the 
R14.0.1 branch automatically becomes the R14.0.2 or R14.1.0 branch 
after the tarballs are released. We need only maintain the main 
trunk and the next maintenance release branch. Simple.

We will need to plan future releases. That way we know exactly what 
to backport and when.


Our goals with the 90-day cycle is not to play the idiotic version 
scheme of some well-known software. Our goals include 1) ensuring 
bug fixes are released in a timely manner and 2) keeping Trinity in 
the public eye.

After R14.0.0 we need to keep bug and security patches rolling. The 
ultra long R14 cycle has been a grand exception.

A nominal press release every 90 days keeps Trinity in the news. A 
90-day release cycle keeps the bug patches flowing in a timely 

Yes, the 90-day schedule is intended to be hard-fast. Whether we 
release with 3 bug fixes or 30 is irrelevant. We release every 90 

No, the 90-day schedule is not intended to be a rapid release 
schedule. The focus is very much timely releases of bug patches.

We can release sooner than 90 days but only when a show stopper bug 
slips by all of us and cause great pain for users. Likewise for 
severe security issues.

By design, each maintenance release will increment the last number 
in the version sequence: R14.0.1, R14.0.2, etc.

Renaming changes and new features will increment the MINOR number 
in the version sequence: R14.1.0, R14.2.0, etc.


A significant difference between future maintenance releases and and is we won't suffer the challenge of renaming. 
The bug fix patches included in the 3.5.13.x releases all had to 
revert renaming changes. That was a huge burden. That will not 
happen in future maintenance releases. We will have no need to 
revert renaming changes in the maintenance release cycle. All we 
need do with future renaming changes is bump the MINOR version 

Future renaming changes are <FEATURE REVISION> and not <BUG AND 
SECURITY PATCH LEVEL>. The first set of renaming changes after 
R14.0.0 bumps the version to R14.1.0. This includes cmake 
conversions. We have seen renaming changes introduce severe bugs. 
We will need to plan and test renaming changes in the main trunk 
before backporting to the next maintenance release.

We need to discipline ourselves. Unlike the R14 cycle, we need to 
plan renaming events. There are many apps that we can and should 
rename. tdevelop and tdesdk remain a convoluted mess of tde* and 
kde* names. We don't blindly push such patches. We agree on when 
such patches will be pushed. We agree on when such patches are 
backported. Agreeing on such patches will reduce stress and help 
maintain the multiple branches in a sane manner.

We can push almost anything into the main trunk, but what gets 
pulled into the next maintenance release branch should be a part of 
a plan. For example, R14.0.1: bug fixes only. R14.1.0: tde-i18n 
changes and bug fixes. R14.1.1: bug fixes. Bug fixes always get 
backported to the next maintenance release branch. Other patches 
might not get backported immediately, but if we backport more than 
bug fixes then we bump the MINOR number.

All of us involved at the development level will need to learn from 
other projects how people maintain different branches. For example, 
the LO folks now have a main trunk, a 4.2 branch, a 4.1 branch, a 
3.6 branch. How do they decide what gets backported? Yet they seem 
to handle this with no problems. We learn how to do likewise.


To summarize:

Maintenance releases will be released as tarballs. Users are never 
affected by anything that happens in the main trunk. Easy to forget 
that those of us using git are volunteer guinea pigs. Users are not.

This is not a rapid release schedule. Primarily this is a focus on 
timely releases of bug fixes and planned feature releases.

Future releases will be planned.

At the moment I'm comfortable with the current version scheme and 
am not in favor of pushing the main trunk as an official release.