Hacker News Reader

Comment by shadowgovt | Hacker News Reader

I'm not sure what the author (or Yegge, for that matter) expect a good timeframe to be for deprecating services.

Anecdotally, Google announced the changeover of Cloud logging API versions in October of 2016, with a 5-month ramp (October to March) to switch from the v1 beta API to the v2 beta API. Five months is nearly two quarters, which is quite a long window for a beta API IMHO.

That having been said, Google's habit of leaving things that are pretty much mission-critical in beta is unwise, but it should be unwise for them, not end-users. End-users that need reliability and low churn shouldn't be developing on beta-anything.

View on HN

About deprecation: the gold standard is what AWS is doing with SimpleDB: essentially, never.

The thing here is that if you run hundreds of services in production - many of which work smoothly and you don't need to touch often, you will find that Google's habit of forcing you to change how to use their tooling will generate a huge burden...

They discourage you from using it and make it clear that for every use case some other tool at AWS would be best, and have been doing so for several years now... They wont even list it anymore under https://aws.amazon.com/products/databases/ ..

Still, they support it ( https://aws.amazon.com/simpledb/ ) because there are customers with legacy systems that depend upon this service.

When I was doing deprecations on GCP, it was minimum 12 months for any deprecation. Five seems shockingly fast!

As for the beta thing: GCP's definition of beta was basically everyone else's definition of GA, since the GA requirements were so insane (e.g. 99.999% internal availability) that getting there would take literal years (see the GCF beta to GA taking like 18 months?). I totally agree that it's weird that things would stay in beta for so long, as opposed to hitting industry standard levels so users can have confidence in them, but setting GA as far higher than the industry was part of Google Cloud's plan.

I can vouch that’s not a true statement. The deprecation policy doesn’t cover breaking api changes. Forced k8s version upgrades.

Among other edge cases that caused pain.

I'd want 5 years at the minimum?

Giant changes like that are worth capturing in long term planning processes, and then you need time to get ramped up on the new stack, design and implement the replacements, run all your backfills, and also, still have a couple years to figure out the parts that don't migrate nicely. With enough time available, you also don't have to drop actual business related improvements, even if your progress slows down a bit

I thought Yegge was rather specific about what he thought. He specifically mentioned a bunch of things (Java, emacs, AWS, Android, browsers) that take the approach to deprecation that he wished to see.

I would sum up his ideas as: "If you offer a service I pay for, and deploy code on, you should not break my code while you still offer the product."

I also don't think he'd have bothered to mention one or two minor things. His examples were rampant and incredibly bad, like breaking their own offerings.

Reply on news.ycombinator.com