Re: [HACKERS] Function-manager redesign: second draft (long)
От | wieck@debis.com (Jan Wieck) |
---|---|
Тема | Re: [HACKERS] Function-manager redesign: second draft (long) |
Дата | |
Msg-id | m11iT17-0003kLC@orion.SAPserv.Hamburg.dsh.de обсуждение исходный текст |
Ответ на | Re: [HACKERS] Function-manager redesign: second draft (long) (Peter Eisentraut <peter_e@gmx.net>) |
Ответы |
Re: [HACKERS] Function-manager redesign: second draft (long)
|
Список | pgsql-hackers |
Peter Eisentraut wrote: > On Oct 30, Jan Wieck mentioned: > > > Right. A major release is what it is. And porting > > applications to a new major release too, it is a conversion, > > not an upgrade. Therefore a major release should drop as much > > backward compatibility code for minor releases as possible. > > Certainly true. But that would also mean that we'd have to keep > maintaining the 6.* series as well. At least bug-fixing and releasing one > or two more 6.5.x versions. Up until now the usual answer to a bug was > "upgrade to latest version". But if you break compatibility you can't do > that any more. (Compare to Linux 2.0 vs 2.2) I'm just wondering what the > plans are in that regard. Sometimes ago, I already pointed out that we have to support one or too older releases for some time. Not only because we might drop some compatibility code. Each release usually declares one or the other new keyword, making existing applications probably fail with the new release. And no amount of compatibility code would help in that case! It's a deadlock trap, an application that cannot be easily ported to a newer release because of incompatibilities in the querylaguage cannot use the last release it is compatible to because of a bug. There is a new aspect in this discussion since then. The new corporation PostgreSQL Inc. offers commercial support for our database (look at www.pgsql.com). If they offer support, they must support older releases as well, so they need to backpatch already. Wouldn't it be a good idea if their return into our project are bugfix releases of older versions (created by backpatching release branches)? In the case of a customers accident, they have to do it anyway. And doing it for critical bugs during idle time could avoid accidents, so it's good customer service. Marc, what do you think about a such an agreement? Jan -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #========================================= wieck@debis.com (Jan Wieck) #
В списке pgsql-hackers по дате отправления: