[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: PostgreSQL release cycles and LedgerSMB 1.3



On Mon, Jun 13, 2011 at 6:47 PM, Adam Thompson <..hidden..> wrote:

>
> Any new installation of LSMB would, presumably, also occur on a new OS.
> Upgrades are a different problem, of course.  The two most conservative
> OSes/distros are generally Debian and Red Hat.  Red Hat (and CentOS, SL,
> etc.) defaults to Pg8.1 for the package name "postgres", but also supply
> Pg8.4 under the package name "postgres84".
> Were it not for that, I would argue that you should only support >= Pg9.0.
> However, given that RHEL5.x is still considered a mainstream, viable
> system, and continues to be installed anew (I did one last week) it's a
> useful benchmark.
> I don't know what Debian or RHEL6 provide.

I guess I am looking at this a little differently but along similar lines.

The big issue here is that when you look at an upgrade you are talking
about something that is not only on an existing OS, but also
presumably on an existing RDBMS.  Insisting, as a general policy, that
we support all existing versions of Pg will probably get us nowhere.
At some point it is worth insisting that users who want to upgrade
also upgrade their RDBMS.  I think we should tie this to two
considerations:

1)  Are there new features  in new versions we NEED. This was the
original reason for requiring 8.1 on 1.3.

2)  What versions have easy to obtain, long-term support options
available?  I personally think it is worth tying this to what versions
are maintained at postgresql.org and seeing support from the likes of
Red Hat to be transitional only.  In other words, the programs are
nearing end of life there, and should be upgraded at earliest
convenience anyway.  Given that the window is fairly small, delaying
an upgrade of the accounting software to coincide with an upgrade of
the database software doesn't strike me as a major problem.

The fact is that nearly all the maintenance effort goes into the
versions on Postgresql.org's web site.

I guess so my question in whether this is reasonable is whether it is
worth supporting database systems that are about to be (or have been)
EOL'd by commercial vendors

Best Wishes,
Chris Travers