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
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/#namin...
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-majo..., 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.
On 02/12/2014 11:21 AM, David C. Rankin wrote:
package-major.minor.micro-rel.arch.(compression
http://www.tldp.org/HOWTO/html_single/Software-Release-Practice-HOWTO/#namin...
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-majo..., comment 12:
[YYYY].[MM].[DD].[hh][mm] has no meaning. It's just a coincidental binding between a moment in time and a release
Another good page for consideration:
One thing to point out against Darrells points:
"NO. NO "rapid fire", "rabbit pellet" releases. This is a disaster waiting to happen. That is the kde4, firefox, mandrake debacle all over again."
Look at LibreOffice. Before there were almost NEVER releases with OO.org, but libreoffice continually chugs away at new releases, every 4 months I think. That way I am constantly getting the improvements over time. If we don't release often enough, what happens is that people will just start using the nightly-builds more. That is why it's important to have seperate development branches.
For example, LO has a stable branch, and does bugfix releases on it(akin to TDE 3.5.X i guess), and continues to push new changes to their new branch.
Now why faster releases are good:
Faster releases also means bugfixes go out faster to users, not waiting 2 years to get a small fix for something simple like a konqueror loading error.
Enough drops in the bucket and you end up with a bucket full. You guys are working hard on bug patches, so the sooner they get out to users the better the project will appear to end users, and the happier they will be.
What it really adds up to is an insane amount of discipline when it comes to GIT, doing all new features in a seperate branch for example, keeping master very stable, and merging those new features in only during preperation for a release period. There are a plethora of ideas on how to properly use version control, but that is one way I can think of to have users getting good fixes frequently, and new features less often (but only after they're stable)
I think like everything, moderation is good. There's always the tug and pull or wanting to get users fixes, but not wanting to screw anything up
Sorry for my long winded speech
Calvin
On 02/12/2014 12:01 PM, Calvin Morrison wrote:
I think like everything, moderation is good. There's always the tug and pull or wanting to get users fixes, but not wanting to screw anything up
Sorry for my long winded speech
No need, it is a good discussion. I did not say not to do bug fixes or improvements, what I said was make minor version/release bumps "mean something". What I said was:
<quote> ...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. </quote>
What I also said was tying a release to time is meaningless. Again, version number changes major/minor mean something. Significant changes, deprecation in API fuctions, or breaks in backwards compatibility, if not, just implement the change as a R14.0.0-Num change.
The same applies to the packaging/naming standards. If we are going to release as R14, then it is R14.0.0-X until there are major changes or deprecations and then it becomes R14.0.1-X. When there are breaks with compatibility we have R14.1.0-X. And when we want to make it no longer look/feel, behave or perform like traditional KDE3, then we have
(something else).0.0-1
Lastly before we schedule R14.0.1-X for release, we need to know what major changes are going into R14.0.1, otherwise, it is a release just for the sake of release. That is what is to be avoided.
I have never been a fan of R14 for a name because I saw no continuity or relationship between 3.5.13 and R14. I saw far more logic in 3.5.14 (but that does not follow standards since there are breaks in compatibility) so 3.6.0 made more since to me. And... knowing there was never a KDE 3.6 it did more than enough to signify a break/change with KDE while continuing the traditional look an feel. But, being a team player, I'll go with R14.0.0 even though package managers never like package versions that start with a 'letter'.....
trinity-R14.0.0-1.i686.tar.xz, though
tde-R14.0.0-1.i686.tar.xz speaks volumes more about what the desktop is and where it came from.
tde-3.6.0-1.i686.tar.xz says it all...
Like I said, for discussion purposes, this is what logic says to me. That doesn't mean something else is more/less wrong.
[snip] trinity-R14.0.0-1.i686.tar.xz, though
tde-R14.0.0-1.i686.tar.xz speaks volumes more about what the desktop is and where it came from.
tde-3.6.0-1.i686.tar.xz says it all...
Like I said, for discussion purposes, this is what logic says to me. That doesn't mean something else is more/less wrong.
tde-3.6.0-1.i686.tar.xz will raise less questions and give a strong hint for continuity. Just my 2 cents.
Nik
On Wednesday 12 of February 2014 20:30:37 David C. Rankin wrote:
I have never been a fan of R14 for a name because I saw no continuity or relationship between 3.5.13 and R14. I saw far more logic in 3.5.14 (but that does not follow standards since there are breaks in compatibility) so 3.6.0 made more since to me. And... knowing there was never a KDE 3.6 it did more than enough to signify a break/change with KDE while continuing the traditional look an feel. But, being a team player, I'll go with R14.0.0 even though package managers never like package versions that start with a 'letter'.....
trinity-R14.0.0-1.i686.tar.xz, though
tde-R14.0.0-1.i686.tar.xz speaks volumes more about what the desktop is and where it came from.
tde-3.6.0-1.i686.tar.xz says it all...
Like I said, for discussion purposes, this is what logic says to me. That doesn't mean something else is more/less wrong.
For this I have a simple explanations:
1) The terms "Trinity"/"TDE" is to replace term "KDE 3.5" => there is no need to repeat "3.5." in the version numbers. Therefore, the after "13" followed "14".
2) With numbering "3.5.x" remains for us little room for detailed numbers. Therefore, we temporarily created 3.5.13.x. With version 14, so we can get back to three numbers.
3) Release "14" underwent a significant profiling own identity - many renaming, own XDG name,... Therefore, now gets its own "minor" and "micro/patch" versioning.
For these reasons, numbering 14.x.y feels good for me. The letter 'R' can be omitted in the version of the packages. Moreover, on some distributions package version MUST start with a number, not a letter. Therefore I do not expect use the letter 'R' in the version of the packages, in the version of source tarballs, neither in GIT tag.
Slavek --
On 02/12/2014 04:56 PM, Slávek Banko wrote:
For these reasons, numbering 14.x.y feels good for me. The letter 'R' can be omitted in the version of the packages. Moreover, on some distributions package version MUST start with a number, not a letter. Therefore I do not expect use the letter 'R' in the version of the packages, in the version of source tarballs, neither in GIT tag.
That's how I originally built all my packages:
tde-14.0.0-1.i686.tar.xz
I'm good with that numbering an rpm and pacman package managers will like that much better too.
I still think the "have everyone assume the vanishing parts of '3.5.'14" so they understand what/where TDE came from is a ..s t r e t c h..
I know you have a vested interest in that name, but like I said, I don't, and never have, seen the logic in releasing R14 as 14whatever. I saw the value in calling development code R14 verses 3.5.13 so we clearly knew what body of code was being referred to internally, but as an official version, I think the name is misplaced.
Like I said, I'm a team player, I'll defer to whatever you want to call it, but as we have just been through discussing versioning, we better be darn sure we like whatever it is officially released as, because that is damn sure what it will be from now on....
I vote for something more logical and in-step with standard versioning, but I'll go with whatever, just be sure that is what we want this desktop known as from now on.
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 --
-
Calvin Morrison -
David C. Rankin -
Dr. Nikolaus Klepp -
Michele Calgaro -
Slávek Banko