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 everything. 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 3.5.13.1 and 3.5.13.2 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: R <ABI VERSION> . <FEATURE REVISION> . <BUG AND SECURITY PATCH LEVEL> 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 existing features are significantly updated. A FEATURE REVISION release does NOT include ABI changes. A new FEATURE REVISION level always resets the BUG AND SECURITY PATCHLEVEL. A new ABI version resets both the FEATURE REVISION and BUG AND SECURITY PATCH LEVEL. =========================== 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 proceed. 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 translation). * 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 manner. 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 days. 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 3.5.13.1 and 3.5.13.2 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 number. 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. Darrell