On Fri, Jan 29, 2010 at 18:34, Greg Sabino Mullane <greg@xxxxxxxxxxxx> wrote: > >>> yet, so that page should be listing 7.4.27. Further, shouldn't we be keeping >>> even 'unsupported' versions on this page, so (e.g. case of check_postgres.pl) >>> clients can check if they have the latest revision, even if the major/minor >>> combo is super old? > >> No, I don't think we should. We should list supported versions only. >> And check_postgres could be advised to throw a warning at least if >> you're running an unsupported version ;) > > I'm not sure how useful that is. Surely while we encourage people to run > a recent major version, we also want to encourage people who will not > or cannot upgrade to at least be running the latest revision of a branch, > no matter how old it is? We don't support 7.3. Not even if you run the latest version. > How about a compromise? We add a new field to that XML so we can state > that it is unsupported, but leave it in there. That way, programs such > as check_postgres can not only distinguish between old but valid versions > and invalid versions (e.g. "7.typo.oops") but can act in a more intelligent > way for unsupported versions. Heck, maybe an estimated end-of-life date > field for all versions as well? How do you add that field in a backwards compatible way? Meaning that people or tools relying on it should *not* see 7.3 or 6.1 or whatever. And it needs to be done within the RSS spec (which does allow custom namespaces though, so that may not be a problem) As for an estimated end-of-life, yes, we could definitely add that. Now that we finally have it :-) > Either way, please add 7.4 back in. :) Done, will be on in the next site rebuild. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
