12 Feb
2014
12 Feb
'14
5:43 a.m.
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
12 Feb
12 Feb
5:21 p.m.
New subject: [trinity-devel] Alternative release version numbering scheme proposal
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/#nami…
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-maj…,
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.
5:24 p.m.
New subject: [trinity-devel] Alternative release version numbering scheme proposal
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/#nami…
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-maj…,
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:
http://semver.org/
--
David C. Rankin, J.D.,P.E.
6:01 p.m.
New subject: [trinity-devel] Alternative release version numbering scheme proposal
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
7:30 p.m.
New subject: [trinity-devel] Alternative release version numbering scheme proposal
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.
--
David C. Rankin, J.D.,P.E.
7:45 p.m.
New subject: [trinity-devel] Alternative release version numbering scheme proposal
[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
--
Please do not email me anything that you are not comfortable also sharing with the NSA.
10:56 p.m.
New subject: [trinity-devel] Alternative release version numbering scheme proposal
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
--
13 Feb
13 Feb
midnight
New subject: [trinity-devel] Alternative release version numbering scheme proposal
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.
--
David C. Rankin, J.D.,P.E.
12 Feb
12 Feb
10:27 p.m.
New subject: [trinity-devel] Alternative release version numbering scheme proposal
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
--
4013
days inactive
4014
days old
8 comments
5 participants
participants (5)
-
Calvin Morrison -
David C. Rankin -
Dr. Nikolaus Klepp -
Michele Calgaro -
Slávek Banko