Greetings, * Andres Freund (and...@anarazel.de) wrote: > On 2019-02-24 17:19:22 -0500, Stephen Frost wrote: > > You say above that the new interface is unquestionably an improvement > > FWIW, I think we didn't design it even remotely as well as we ought to > have. It was both a mistake to not offer a version of non-exclusive > backups that works with a client connection (for integration with the > TSMs of this world), and it was a mistake not to offer a commandline > tool that does the non-exclusive pg/start backup.
I'm not really following- did you mean to say "without a client connection" above? We could still add some kind of commandline tool to help with the non-exclusive pg start/stop backup but I'm not really sure exactly what that would look like and I honestly don't have terribly much interest in spending resources on implementing it since it would lack a great many features that we'd then end up wanting to add on... and then we end up backing into building yet another backup tool. > > I really, honestly, believe what we need to *stop* doing is trying to > > drag along support for old/deprecated interfaces after we've introduced > > new ones, thus avoiding these arguments and the time spent on them, and > > the time spent dealing with implementing and documenting new APIs around > > old ones. The only thing it seems to unquestionably do is make us argue > > about when we are going to *finally* rip out the old/deprecated API (or > > interface, or whatever you want to call it). > > While I agree that we should remove non-exclusive backups, I VEHEMENTLY > oppose the unconditionality of the above statement. Yes, it's annoying > to keep interfaces around, but unnecessarily inflicting pain to everyone > also is annoying. Alright, then how about we provide a bit of help for everyone who's got a system built around recovery.conf today, instead of just completely ripping that out? If we're happy to do that then I really can't agree with these arguments that there's things we should try to maintain when it comes to interfaces, and that's far from the only example of a pretty massive change that just went into version X with zero notice to users about what they're using today being deprecated. > That's not to say we shouldn't be better at announcing and then > following through on the deprecation of old interfaces. We announce things have changed every year, and people have five years from that point, during which we'll continue to support them and fix bugs and deal with security issues, to make whatever changes they need to for the new interface. The argument seems to be that people want new features but they don't want to have to do any work to get those new features. Instead, they expect the community to take on the burden of maintaining those old interfaces for them, so that they can get those new features. That seems like a pretty raw deal for the community and not one that I really think we should be supporting, and it isn't like we're actually consistent with it at all- except that we don't break the back-branches and we do make breaking changes in major versions. When is something too big of a change to make in a given major version and we have to, instead, provide backwards compatibility for it? What is that policy? How many releases do we have to support it for? How do we communicate that to our users, so that they know what they can depend on being there across major releases and what they can't? Thanks! Stephen
signature.asc
Description: PGP signature
