Marc G. Fournier wrote:
> On Tue, 13 Jul 2004, Bruce Momjian wrote:
>
> >> The nice thing about doing something lke that is those small features
> >> would get a degree of testing happening in a live environment ...
> >
> > Of course that last sentence is the downside too --- people don't want
> > to have to retest their setups after a minor release upgrade.
>
> Nobody would be required to upgrade to a new minor release either ...
> nobody is *require* to upgrade to any release, for that matter ...
>
> Hell, when we have a client that comes to us with a problem, we don't
> recommend upgrading unless we find something in the RELEASE NOTES to
> indicate something has been fixed related to their problem ... it isn't a
> automatic "well, upgrade to the latest stable first, and then we can help
> you" ...
>
> God, we still have clients using 7.2 servers, cause they've had no reason
> yet to upgrade to the latest ... "it works, why upgrade?" is generally the
> opinion ...
We have always recommended upgrading to the most recent minor release,
at least as a project policy for support. Also, the upgrade is only
stop/install/restart so it is quite easy to do, and folks like the fact
they don't have to test for new functionality.
One idea would be for us to release 7.5 and 7.5.0.1, and allow 7.5.1 to
have minor new features. That way, 7.5.0.[1-9] are no new features, and
7.5.[1-9] are minor improvements against 7.5.
Of course this does require more project management, and we already
don't have enough manpower.
I was thinking of something much simpler where Jan would create an ARC
patch against 7.4.X and have it either in /contrib for 7.4.X or on our
ftp servers, or on a web site. I could create a mechanism so SELECT
version() would display Jan's add-on.
-- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610)
359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square,
Pennsylvania19073