On Mon, Mar 20, 2017 at 11:40:34AM -0400, Tom Lane wrote: > Stephen Frost <sfr...@snowman.net> writes: > > * Bruce Momjian (br...@momjian.us) wrote: > >> 1. make the change now and mention it in the release notes > >> 2. #1, but also provide backward compatibility for 5+ years > >> 3. mark the feature as deprecated and remove/change it in 5+ years > >> 4. #3, but issue a warning for deprecated usage > > > I don't generally feel like #1 is so rarely used (nor do I think it > > should be rare that we use it). With regard to #2, if we're going to do > > that, I'd really like to see us decide ahead of time on a point in time > > when we will remove the backwards-compatibility, otherwise it seems to > > live on forever. For my 2c, #3 should be reserved for things we are > > explicitly removing, not for things we're changing and we should do #4 > > whenever possible in those cases because we're going to be removing it. > > > Otherwise, #3 ends up being a case where we're holding up progress for > > years because we have to announce that we're going to deprecate > > something and then wait before we actually make whatever the change is. > > Well, to what extent are we "holding up progress" in this particular > case? There is no other development work that's stalled by not renaming > these binaries. I think there should be some explicit accounting for > the impact of delay if we're going to try to formalize these decisions > better.
I mentioned the problem of "confuse users" for #2. What delay are you talking about? #3 and #4? -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
