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