> eh.. i could see some things, like tsearch2 or pg_autovacuum, which
> afaik are almost if not completely compatible with 7.3, which will not
> get back ported. Also fixes in some of the extra tools like psql could
> be very doable, I know I had a custom psql for 7.2 that back patched the
> \timing option and some of the pager fixes. now, weather that could be
> done with stuff closer to core, i don't know...
Sure but businesses don't like to upgrade unless they have too. If we
really want to attract more business to using PostgreSQL then they need
to feel like they don't have to upgrade every 12 months. Upgrading is
expensive and it rarely goes as smoothly as a dump/restore.
> > Furthermore, adding more features to 7.3.x reduces the incentive to
> > upgrade to 7.4, worsening the support problem: the more people using old
> > releases, the more demand there will be for backported features, leading
> > to more people using 7.3, leading to more demand for ...
I am considering a time limited type thing. Not open ended. Something like
18 or 24 months (max) from release of the new version. You can't expect
business to consider that timeframe during the development of the new
release. They want to see the new release in action for a period of time.
They also want time to play with the new release without sacrificing
support for the previous release.
> <homer>mmm. in place upgrade</homer>
In reality in place upgrade will never work. Sure we can build a script
that will deal with PostgreSQL itself, but not user defined data types,
operators, functions etc... Those are all things that need stable time to
migrate and test.
Sincerely,
Joshua Drake
>
> Robert Treat
>
--
Co-Founder
Command Prompt, Inc.
The wheel's spinning but the hamster's dead