Re: Upgrading rant. - Mailing list pgsql-hackers
From | Lamar Owen |
---|---|
Subject | Re: Upgrading rant. |
Date | |
Msg-id | 200301031516.34384.lamar.owen@wgcr.org Whole thread Raw |
In response to | Re: Upgrading rant. (Tom Lane <tgl@sss.pgh.pa.us>) |
Responses |
Re: Upgrading rant.
|
List | pgsql-hackers |
On Thursday 02 January 2003 19:26, Tom Lane wrote: > Lamar Owen <lamar.owen@wgcr.org> writes: > > So I figured I'd roll a 7.1.3 RPMset for him to install onto Red Hat 8. > > It was very bad. It simply would not build -- I guess it's the gcc 3 > > stuff. > If you don't know *exactly* why it doesn't build, I don't think you > should be blaming us for it. Who did I blame? (no one). I just made a statement -- which you pretty much agreed with later (gcc --version being multiline IS a gcc 3 problem, no? :-)). No blame at all. None of the message was a blame game of any kind, although you seem to take it personally every time I bring up upgrading. But, then again, I take it personally when someone e-mails me ranting (and sometimes cussing) about my stupid program's not upgrading (and PostgreSQL isn't 'my' program!). > > THIS DOESN'T HAPPEN WITH MySQL. > Oh? Do they have a crystal ball that lets them predict incompatible > future platform changes? No, they just allow for the old format, while making a new format. At least that's the way it looks from reading the docs and a cursory install run. The Linux Magazine article states it in a quite pointed way -- I'll grab that magazine when I get back home and post a quote if you'd like. > (I'm not very sure I believe your assertion above, anyway. We are > painfully aware of our own compatibility issues, but I wonder how many > people on this list pay close enough attention to MySQL to know what > their version-to-version compatibility track record *really* is.) I pay close enough attention that I was asked by a publisher to do a technical review of a MySQL reference book. > > And I'd love to see someone who has the time to do so (not me) grab > > this bull by the horns and make it happen. > Well, this is exactly the issue: someone would have to put substantial > amounts of time into update mechanisms and/or maintenance of obsolete > versions, as opposed to features, performance improvements, or bug > fixes. Fixing the upgrade 'bug' is a bugfix, IMHO. A _big_ bugfix. > Personally, I feel that if we weren't working as hard as we could on > features/performance/bugfixes, the upgrade issue would be moot because > there wouldn't *be* any reason to upgrade. However, I'm sure there are people who hesitate to upgrade BECAUSE of the difficulty, thereby causing them to miss features. And potentially bugfixes, too. > So I'm not planning to > redirect my priorities. But this is an open source project and every > developer gets to set their own priorities. If you can persuade someone > to put their time into that, go for it. Which is why I shake the branches periodically, to see if I can persuade someone who can do this (in practice this means they either have a great deal of free time, or they are paid fulltime to work on PostgreSQL). > I think you're wasting your time trying to hold us to a higher standard > of backwards-compatibility than is maintained by the OSes and tools we > must sit on top of. I think PostgreSQL already sets a higher standard in many ways. Particularly in the release cycle (we don't 'release early and release often'). -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
pgsql-hackers by date: