[gentoo-dev] Keeping older versions around

[gentoo-dev] Keeping older versions around

[Ryan Hill]

[-- Attachment #1: Type: text/plain, Size: 803 bytes --]

I've run into this three times today, so I'm a little grumpy.  When you bump
to a new ~arch version, please consider keeping at least one previous ~arch
version around, so if people run into major issues they can at lease try the
previously installed version to determine if it's your package at fault.
Recent version bumps to two libraries have completely trashed a package I
maintain, and the only option for my users is downgrading them to stable,
which requires downgrading several other libraries.  In both cases, the
previous ~arch version, which worked fine, was removed.

Personally I always try to keep two versions in ~arch and one stable,
excepting security or other major bugs that render an older version useless.


-- 
fonts, gcc-porting
toolchain, wxwidgets
@ gentoo.org

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Keeping older versions around

[Rich Freeman]

On Sat, Jan 28, 2012 at 10:33 PM, Ryan Hill <dirtyepic@gentoo.org> wrote:
> When you bump
> to a new ~arch version, please consider keeping at least one previous ~arch
> version around, so if people run into major issues they can at lease try the
> previously installed version to determine if it's your package at fault.

I mostly run stable and when I have to pull in the odd ~arch package
it seems like for some of them I'm re-keywording them every third day.
 The stable version doesn't change in 9 months, and the unstable one
changes 47 times, with old versions being dropped instantly so I have
no choice but to move along or risk having a security bug that won't
get GLSA'ed.

Also, if we don't keep unstable versions around there isn't any way to
get them stabilized, making stable more stale.

If a particular unstable version is particularly buggy or otherwise
not something upstream supports then it makes sense to move on.
However, everything has some level of bugs (if you look hard enough)
and if they're pretty minor then we should be asking ourselves if it
is better or worse than the current stable, and if not then it should
be left around if possible as a stable candidate.  Obviously use
common sense.  If we can afford our users the luxury of upgrading at
their leisure we should do so.

Rich

Re: [gentoo-dev] Keeping older versions around

[Donnie Berkholz]

[-- Attachment #1: Type: text/plain, Size: 1144 bytes --]

On 21:33 Sat 28 Jan     , Ryan Hill wrote:
> I've run into this three times today, so I'm a little grumpy.  When you bump
> to a new ~arch version, please consider keeping at least one previous ~arch
> version around, so if people run into major issues they can at lease try the
> previously installed version to determine if it's your package at fault.
> Recent version bumps to two libraries have completely trashed a package I
> maintain, and the only option for my users is downgrading them to stable,
> which requires downgrading several other libraries.  In both cases, the
> previous ~arch version, which worked fine, was removed.
> 
> Personally I always try to keep two versions in ~arch and one stable,
> excepting security or other major bugs that render an older version useless.

Agreed with a slight modification — once you've kept the old 
{stable,~arch} version around for a reasonable amount of time (say 30 
days), you should be safe pulling it.

-- 
Thanks,
Donnie

Donnie Berkholz
Council Member / Sr. Developer, Gentoo Linux <http://dberkholz.com>
Analyst, RedMonk <http://redmonk.com/dberkholz/>

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

[gentoo-dev] Re: Keeping older versions around

[»Q«]

On Sun, 29 Jan 2012 23:17:48 -0600
Donnie Berkholz <dberkholz@gentoo.org> wrote:

> On 21:33 Sat 28 Jan     , Ryan Hill wrote:
> > I've run into this three times today, so I'm a little grumpy.  When
> > you bump to a new ~arch version, please consider keeping at least
> > one previous ~arch version around, so if people run into major
> > issues they can at lease try the previously installed version to
> > determine if it's your package at fault. Recent version bumps to
> > two libraries have completely trashed a package I maintain, and the
> > only option for my users is downgrading them to stable, which
> > requires downgrading several other libraries.  In both cases, the
> > previous ~arch version, which worked fine, was removed.
> > 
> > Personally I always try to keep two versions in ~arch and one
> > stable, excepting security or other major bugs that render an older
> > version useless.
> 
> Agreed with a slight modification — once you've kept the old 
> {stable,~arch} version around for a reasonable amount of time (say 30 
> days), you should be safe pulling it.

As a user, I'd very much like that to be policy.  It would remove the
main reason I stay away from ~ versions, so I'd use more of them and
file more (hopefully useful) bug reports.

Re: [gentoo-dev] Keeping older versions around

[Graham Murray]

Donnie Berkholz <dberkholz@gentoo.org> writes:

> Agreed with a slight modification — once you've kept the old 
> {stable,~arch} version around for a reasonable amount of time (say 30 
> days), you should be safe pulling it.

As long as there are no open bugs on the later ~arch version breaking
other packages.

Re: [gentoo-dev] Keeping older versions around

["Paweł Hajdan, Jr."]

[-- Attachment #1: Type: text/plain, Size: 598 bytes --]

On 1/30/12 6:17 AM, Donnie Berkholz wrote:
> Agreed with a slight modification — once you've kept the old 
> {stable,~arch} version around for a reasonable amount of time (say 30 
> days), you should be safe pulling it.

Agreed with a slight modification ;-)

Please make sure that at _any_ given moment you have an ~arch ebuild
that has spent 30 days in ~arch (unless it's already stabilized).

If you remove such an ebuild after 30 days without stabilizing it, you
can still create a situation where no ebuild can be stabilized because
the existing ~arch ebuilds are too recent.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 203 bytes --]