Hi all,

because our development is always moving forward we sometimes need to
break compatibility with old installations of Arch. For example
switching to xz as compression for all packages of course requires a
version of libarchive which can handle it. Allan's request for bumping
glibc's kernel dependency is similar (but also a special case). Or
imagine some special treatment in install files when updating from old
package versions. We have also had some repository changes which made
updates from very old setups difficult or broke old install isos.

I would suggest to decide on a maximum age within which an update
should be supported. What about one year? That would mean updating a
system which hasn't been updated for more than one year or installing
from an ISO image older than one year might not work.

The benefit of such a defined "rule of thumb" would be that code and
packages can be simplified and we are not hold back by keeping very old
backwards compatibility.

A side effect of this rule would be that keeping your system up to date
is a requirement for using Arch. This is no big deal though and should
affect virtually nobody.

What do you think? Would you agree in general? Is a year too short or
too long?

Greetings,

Pierre

--
Pierre Schmitz, https://users.archlinux.de/~pierre

On Sat, 11 Dec 2010 18:23:27 +0100
Pierre Schmitz <pierre@archlinux.de> wrote:

> Hi all,
>
> because our development is always moving forward we sometimes need to
> break compatibility with old installations of Arch. For example
> switching to xz as compression for all packages of course requires a
> version of libarchive which can handle it. Allan's request for bumping
> glibc's kernel dependency is similar (but also a special case). Or
> imagine some special treatment in install files when updating from old
> package versions. We have also had some repository changes which made
> updates from very old setups difficult or broke old install isos.
>
> I would suggest to decide on a maximum age within which an update
> should be supported. What about one year? That would mean updating a
> system which hasn't been updated for more than one year or installing
> from an ISO image older than one year might not work.
>
> The benefit of such a defined "rule of thumb" would be that code and
> packages can be simplified and we are not hold back by keeping very
> old backwards compatibility.
>
> A side effect of this rule would be that keeping your system up to
> date is a requirement for using Arch. This is no big deal though and
> should affect virtually nobody.
>
> What do you think? Would you agree in general? Is a year too short or
> too long?
>
> Greetings,
>
> Pierre
>

interesting question.
Isn't it already in our guidelines/recommendations somewhere that
Arch users need to update their system regularly (at least weekly or
so), and if they don't like that, Arch is not for them?
I would say we only stretch this support period for the maximum amount
of time needed, not a timeframe we just make up.

As far as I know, the biggest bottleneck are release media.
So I would say: we support upgrade paths from system as old as the
latest official release media, or newer.
In this case, the newest release is 2010.05, so if a users system was
last updated in April, that's too old to still support upgrades.

There is a potential edge case / race condition when new, breaking
features are released shortly after a media release. (or in other
words: users would need to upgrade right away when new official images
are released), maybe we should take oldest release + 1 month, or so.

If we'll ever be at a point where we do frequently official
releases (like each 3 months), we probably don't want to force users
to download the new image if they have one of 3 months old. We can
capture that in our statement as well by saying something like "we
support upgrades on systems as old as the oldest release media whose
age does not exceed 6 months (unless the latest release media are older
then 6 months, in which case we support from then and onwards)"

Dieter

On Sun, 12 Dec 2010 11:28:12 +0100
Dieter Plaetinck <dieter@plaetinck.be> wrote:

> interesting question.
> Isn't it already in our guidelines/recommendations somewhere that
> Arch users need to update their system regularly (at least weekly or
> so), and if they don't like that, Arch is not for them?
> I would say we only stretch this support period for the maximum amount
> of time needed, not a timeframe we just make up.
>
> As far as I know, the biggest bottleneck are release media.
> So I would say: we support upgrade paths from system as old as the
> latest official release media, or newer.
> In this case, the newest release is 2010.05, so if a users system was
> last updated in April, that's too old to still support upgrades.
>
> There is a potential edge case / race condition when new, breaking
> features are released shortly after a media release. (or in other
> words: users would need to upgrade right away when new official images
> are released), maybe we should take oldest release + 1 month, or so.
>
> If we'll ever be at a point where we do frequently official
> releases (like each 3 months), we probably don't want to force users
> to download the new image if they have one of 3 months old. We can
> capture that in our statement as well by saying something like "we
> support upgrades on systems as old as the oldest release media whose
> age does not exceed 6 months (unless the latest release media are
> older then 6 months, in which case we support from then and onwards)"
>
> Dieter

Also, something I implied, but I should probably say explicitly:
I think there's nothing inherently bad about being relatively strict in
what we support.
Currently, a lot of systems already have something unsupported about
them (packages from aur, unofficial mirrors/repos, recompiled from ABS,
ignorepkg/ignoregroup/noupgrade settings, etc). If you know what
you're doing there's no problem. This is why I think we shouldn't
stretch the support period needlessly, those who know what they are
doing can keep an old system if they want that.


Dieter