Version bump policies and beta packages in stable branch
"Frantz Dhin" <[email protected]> Sat, 24 Jan 2004 06:29:17 +0100
| Newsgroups | gmane.linux.zynot.zynaut |
|---|---|
| Message-ID | <[email protected]> |
This is a multi-part message in MIME format.
--===============1324101855==
Content-Type: multipart/alternative;
boundary="----=_NextPart_000_0007_01C3E243.6484B210"
This is a multi-part message in MIME format.
------=_NextPart_000_0007_01C3E243.6484B210
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: 7bit
Hello all,
So we have this problem that I'd like to put up here for discussion. It has
been boggling my mind for quite a while.
The problem:
Best summarized using the Gentoo distribution as an example. In Gentoo you
basically have a choice of 2 distributions. A stable and an unstable branch.
Some would like you to believe that a choice between a wealth of package
versions exists in this "meta distribution", but in reality you are limited
to these two package sets.
If you type "emerge mysql" on the command line in Gentoo today you get
version 4.0.16 if you are running the stable branch, and 4.0.17 if you are
running unstable. Now question is: Where are v4.1 and v5.0 versions of MySQL
in the Portage tree? Answer: They are not there. So when will they be there
and when will stable or unstable versions suddenly prompt you to upgrade?
Good question that only the package maintainer can answer.
Now the problem in performing a MySQL v4.0 to v4.1 upgrade will be that some
upgrading will need to be done on the database tables themselves. In other
words a 4.0 database is most likely not compatible with a 4.1 database. For
a database of a reasonable size this is no trivial operation. It will
require planning, testing and a good chunk of human resource time. It is an
operation that needs to be carried out at a time of convenience.
For a while Gentoo was running with MySQL 3.23 in the stable branch and
4.0.x in the unstable branch. One day the package maintainer decided that
now it was time to "move v4.0.x to stable" and announced this on gentoo-dev
mailing list, and so it became.
I hope everyone is now beginning to see the problem. What happens when it is
time to move 4.1 into unstable or stable? How many oopses will we hear the
users say? How much annoyance is it going to cause when a package manager
constantly offers you a package upgrade that you don't have time for or may
not even want for years to come? And what happens when you in 2 years badly
need to restore your MySQL 4.0 system fast and smooth. - Is the ebuild for
the exact version you need still guaranteed to be there and accessible for
you?
A workaround could be to split it into 3 separate packages named such as
these. The naming is taken from mysql.com.
Mysql-production-release (Currently 4.0.x)
Mysql-alpha-release (Currently 4.1.x)
Mysql-development-tree (Currently 5.0.x)
But really that is just delaying and making a half solution to the problem,
because there will be a day where v4.1 will be recommended as the current
"production release".
I have here used Gentoo and MySQL as an example. Not intended as flaming,
but to illustrate a problem of a more general nature. Think of Apache 1.3.x
and 2.0.x which are both used in production and will be for a long time
still. Think of the Gimp (1.2.x) and the beta version of it (1.3.x) which
also get version incremented independently in both branches.
In Gentoo it was for a while as such that if you were running stable you got
Gimp 1.2 and if you were running unstable you got Gimp 1.3 handed to you.
IMHO you should have the choice of both no matter what OS branch you run,
but here obviously separating into 2 packages and naming them gimp and
gimp-beta would suffice.
To conclude this I suggest a general policy for the trees we develop to
provide as much choice as possible when it comes to running beta packages in
a so-called 'stable' release. We should, especially for desktop
applications, avoid forcing a whole set or branch of packages on a user who
in all innocence is curious about what the beta release of Gimp is like.
It would all-in-all be a more effective use of having a stable vs an
unstable branch if, for instance, gimp 1.2.4 and gimp-beta 1.3.22 were
placed in stable, while gimp 1.2.5 and gimp-beta 1.2.23 were in testing
stage. I suggest making this a general principle as long as the technical
implications do not become too much of a burden. I realize that running a
beta of an application could force an upgrade of a bunch of libs which again
could break a lot of things. I imagine a beta of Evolution for instance
would have this trait, so a policy like this of course has to be kept within
reason.
Furthermore, not neglecting the problem with a package such as MySQL, I am
still in search for solutions and mechanisms and policies to handle this
exact problem. Do not forget that we seek to create a data center worthy
distribution. The demands for such a distribution is that it can be
installed on large machinery and clusters and be able to run the next 15
years with 99.999% uptime. Take this into account, but I am eager to hear
comments and proposals for solutions.
Best Regards
Frantz Dhin
CEO, Zynot Foundation
------=_NextPart_000_0007_01C3E243.6484B210
Content-Type: text/html;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
<html xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:st1=3D"urn:schemas-microsoft-com:office:smarttags" =
xmlns=3D"http://www.w3.org/TR/REC-html40">
<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
name=3D"City"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
name=3D"place"/>
<!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
<style>
<!--
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman";}
a:link, span.MsoHyperlink
{color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{color:purple;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-compose;
font-family:Arial;
color:windowtext;}
@page Section1
{size:612.0pt 792.0pt;
margin:72.0pt 90.0pt 72.0pt 90.0pt;}
div.Section1
{page:Section1;}
-->
</style>
</head>
<body lang=3DEN-US link=3Dblue vlink=3Dpurple>
<div class=3DSection1>
<p class=3DMsoNormal><font size=3D3 face=3DArial><span =
style=3D'font-size:12.0pt;
font-family:Arial'>Hello all,<o:p></o:p></span></font></p>
<p class=3DMsoNormal><font size=3D3 face=3DArial><span =
style=3D'font-size:12.0pt;
font-family:Arial'>So we have this problem that I’d like to put up =
here
for discussion. It has been boggling my mind for quite a =
while.<o:p></o:p></span></font></p>
<p class=3DMsoNormal><font size=3D3 face=3DArial><span =
style=3D'font-size:12.0pt;
font-family:Arial'><o:p> </o:p></span></font></p>
<p class=3DMsoNormal><font size=3D3 face=3DArial><span =
style=3D'font-size:12.0pt;
font-family:Arial'>The problem:<o:p></o:p></span></font></p>
<p class=3DMsoNormal><font size=3D3 face=3DArial><span =
style=3D'font-size:12.0pt;
font-family:Arial'>Best summarized using the Gentoo distribution as an =
example.
In Gentoo you basically have a choice of 2 distributions. A stable and =
an
unstable branch. Some would like you to believe that a choice between a =
wealth
of package versions exists in this “meta distribution”, but =
in
reality you are limited to these two package =
sets.<o:p></o:p></span></font></p>
<p class=3DMsoNormal><font size=3D3 face=3DArial><span =
style=3D'font-size:12.0pt;
font-family:Arial'>If you type “emerge mysql” on the command =
line
in Gentoo today you get version 4.0.16 if you are running the stable =
branch, and
4.0.17 if you are running unstable. Now question is: Where are v4.1 and =
v5.0
versions of MySQL in the <st1:City w:st=3D"on"><st1:place =
w:st=3D"on">Portage</st1:place></st1:City>
tree? Answer: They are not there. So when will they be there and when =
will
stable or unstable versions suddenly prompt you to upgrade? Good =
question that
only the package maintainer can answer.<o:p></o:p></span></font></p>
<p class=3DMsoNormal><font size=3D3 face=3DArial><span =
style=3D'font-size:12.0pt;
font-family:Arial'>Now the problem in performing a MySQL v4.0 to v4.1 =
upgrade
will be that some upgrading will need to be done on the database tables
themselves. In other words a 4.0 database is most likely not compatible =
with a
4.1 database. For a database of a reasonable size this is no trivial =
operation.
It will require planning, testing and a good chunk of human resource =
time. It
is an operation that needs to be carried out at a time of =
convenience.<o:p></o:p></span></font></p>
<p class=3DMsoNormal><font size=3D3 face=3DArial><span =
style=3D'font-size:12.0pt;
font-family:Arial'>For a while Gentoo was running with MySQL 3.23 in the =
stable
branch and 4.0.x in the unstable branch. One day the package maintainer =
decided
that now it was time to “move v4.0.x to stable” and =
announced this
on gentoo-dev mailing list, and so it =
became.<o:p></o:p></span></font></p>
<p class=3DMsoNormal><font size=3D3 face=3DArial><span =
style=3D'font-size:12.0pt;
font-family:Arial'>I hope everyone is now beginning to see the problem. =
What
happens when it is time to move 4.1 into unstable or stable? How many =
oopses
will we hear the users say? How much annoyance is it going to cause when =
a
package manager constantly offers you a package upgrade that you =
don’t
have time for or may not even want for years to come? And what happens =
when you
in 2 years badly need to restore your MySQL 4.0 system fast and smooth. =
–
Is the ebuild for the exact version you need still guaranteed to be =
there and
accessible for you?<o:p></o:p></span></font></p>
<p class=3DMsoNormal><font size=3D3 face=3DArial><span =
style=3D'font-size:12.0pt;
font-family:Arial'><o:p> </o:p></span></font></p>
<p class=3DMsoNormal><font size=3D3 face=3DArial><span =
style=3D'font-size:12.0pt;
font-family:Arial'>A workaround could be to split it into 3 separate =
packages
named such as these. The naming is taken from mysql.com. =
<o:p></o:p></span></font></p>
<p class=3DMsoNormal><font size=3D3 face=3DArial><span =
style=3D'font-size:12.0pt;
font-family:Arial'><o:p> </o:p></span></font></p>
<p class=3DMsoNormal><font size=3D3 face=3DArial><span =
style=3D'font-size:12.0pt;
font-family:Arial'>Mysql-production-release (Currently =
4.0.x)<o:p></o:p></span></font></p>
<p class=3DMsoNormal><font size=3D3 face=3DArial><span =
style=3D'font-size:12.0pt;
font-family:Arial'>Mysql-alpha-release (Currently =
4.1.x)<o:p></o:p></span></font></p>
<p class=3DMsoNormal><font size=3D3 face=3DArial><span =
style=3D'font-size:12.0pt;
font-family:Arial'>Mysql-development-tree (Currently =
5.0.x)<o:p></o:p></span></font></p>
<p class=3DMsoNormal><font size=3D3 face=3DArial><span =
style=3D'font-size:12.0pt;
font-family:Arial'><o:p> </o:p></span></font></p>
<p class=3DMsoNormal><font size=3D3 face=3DArial><span =
style=3D'font-size:12.0pt;
font-family:Arial'>But really that is just delaying and making a half =
solution
to the problem, because there will be a day where v4.1 will be =
recommended as
the current “production release”. =
<o:p></o:p></span></font></p>
<p class=3DMsoNormal><font size=3D3 face=3DArial><span =
style=3D'font-size:12.0pt;
font-family:Arial'><o:p> </o:p></span></font></p>
<p class=3DMsoNormal><font size=3D3 face=3DArial><span =
style=3D'font-size:12.0pt;
font-family:Arial'>I have here used Gentoo and MySQL as an example. Not
intended as flaming, but to illustrate a problem of a more general =
nature.
Think of Apache 1.3.x and 2.0.x which are both used in production and =
will be
for a long time still. Think of the Gimp (1.2.x) and the beta version of =
it
(1.3.x) which also get version incremented independently in both =
branches. <o:p></o:p></span></font></p>
<p class=3DMsoNormal><font size=3D3 face=3DArial><span =
style=3D'font-size:12.0pt;
font-family:Arial'>In Gentoo it was for a while as such that if you were
running stable you got Gimp 1.2 and if you were running unstable you got =
Gimp
1.3 handed to you. IMHO you should have the choice of both no matter =
what OS
branch you run, but here obviously separating into 2 packages and naming =
them
gimp and gimp-beta would suffice. <o:p></o:p></span></font></p>
<p class=3DMsoNormal><font size=3D3 face=3DArial><span =
style=3D'font-size:12.0pt;
font-family:Arial'><o:p> </o:p></span></font></p>
<p class=3DMsoNormal><font size=3D3 face=3DArial><span =
style=3D'font-size:12.0pt;
font-family:Arial'>To conclude this I suggest a general policy for the =
trees we
develop to provide as much choice as possible when it comes to running =
beta
packages in a so-called ‘stable’ release. We should, =
especially for
desktop applications, avoid forcing a whole set or branch of packages on =
a user
who in all innocence is curious about what the beta release of Gimp is =
like.<o:p></o:p></span></font></p>
<p class=3DMsoNormal><font size=3D3 face=3DArial><span =
style=3D'font-size:12.0pt;
font-family:Arial'>It would all-in-all be a more effective use of having =
a
stable vs an unstable branch if, for instance, gimp 1.2.4 and gimp-beta =
1.3.22
were placed in stable, while gimp 1.2.5 and gimp-beta 1.2.23 were in =
testing
stage. I suggest making this a general principle as long as the =
technical
implications do not become too much of a burden. I realize that running =
a beta
of an application could force an upgrade of a bunch of libs which again =
could
break a lot of things. I imagine a beta of Evolution for instance would =
have
this trait, so a policy like this of course has to be kept within =
reason.<o:p></o:p></span></font></p>
<p class=3DMsoNormal><font size=3D3 face=3DArial><span =
style=3D'font-size:12.0pt;
font-family:Arial'>Furthermore, not neglecting the problem with a =
package such
as MySQL, I am still in search for solutions and mechanisms and policies =
to
handle this exact problem. Do not forget that we seek to create a data =
center
worthy distribution. The demands for such a distribution is that it can =
be
installed on large machinery and clusters and be able to run the next 15 =
years
with 99.999% uptime. Take this into account, but I am eager to hear =
comments
and proposals for solutions…<o:p></o:p></span></font></p>
<p class=3DMsoNormal><font size=3D3 face=3DArial><span =
style=3D'font-size:12.0pt;
font-family:Arial'><o:p> </o:p></span></font></p>
<p class=3DMsoNormal><font size=3D3 face=3DArial><span =
style=3D'font-size:12.0pt;
font-family:Arial'>Best Regards<o:p></o:p></span></font></p>
<p class=3DMsoNormal><font size=3D3 face=3DArial><span =
style=3D'font-size:12.0pt;
font-family:Arial'><o:p> </o:p></span></font></p>
<p class=3DMsoNormal><font size=3D3 face=3DArial><span =
style=3D'font-size:12.0pt;
font-family:Arial'>Frantz Dhin<o:p></o:p></span></font></p>
<p class=3DMsoNormal><font size=3D3 face=3DArial><span =
style=3D'font-size:12.0pt;
font-family:Arial'>CEO, Zynot Foundation<o:p></o:p></span></font></p>
<p class=3DMsoNormal><font size=3D3 face=3DArial><span =
style=3D'font-size:12.0pt;
font-family:Arial'><o:p> </o:p></span></font></p>
<p class=3DMsoNormal><font size=3D3 face=3DArial><span =
style=3D'font-size:12.0pt;
font-family:Arial'><o:p> </o:p></span></font></p>
</div>
</body>
</html>
------=_NextPart_000_0007_01C3E243.6484B210--
--===============1324101855==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
zynaut mailing list
[email protected]
http://lists.zynot.org/mailman/listinfo/zynaut
--===============1324101855==--