[arch-dev-public] For how long should we support a smooth update?

Allan McRae allan at archlinux.org
Sun Dec 12 20:34:15 EST 2010

On 12/12/10 03:23, Pierre Schmitz 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?

My gut feeling is we should support installing from the installer that 
is one before the latest.  Currently that is 2009-08, but with a new 
installer release that would jump to 2010-05.  It means that there is 
not a fixed guideline on support time.   But that allows the newest 
installer to have issues on some systems and people can still install on 
the one prior and we can assume the issue will be fixed in the next 
installer release (I have seen examples such as this on the forums).

A similar issue is how long provides should be in a package after all 
the official packages are rebuilt with the new package name in their 


More information about the arch-dev-public mailing list