Hacker News Reader

Comment by 0cf8612b2e1e | Hacker News Reader

Not OP, but depending on the industry, this could be enormous amounts of backend work. I have projects that needs to be validated, which effectively means a huge amount of human testing for any change. The Process is confirmed to work on version X.Y.Z and nothing else.

View on HN

I imagine that if this sort of bullheaded google policy persists, companies will start adding “piñatas” into their code that have no real impact and can be changed with barely any validation required.

This lets google beat the version numbers out of it at will.

I'd target an about page or something similar, just have a sentence or two that get picked at random from a selection each build. Then have a monthly build job that runs and publishes.

Luckily there is no regulation in this industry, just demanding customers.

The main issue is that we support way too many different workflows based on customer requirements and actual hardware configuration, and even a slight change to a component often means we have to do manual UX testing.

Ah interesting. Even so for like a small styling change?

A change is a change. I have certainly made a few “safe, meaningless, no possible way it could break something” edits which blew up in some unexpected way. Why take the risk for some inconsequential update? Someone has to sign off on why this commit needs to be fast tracked outside the normal process.

Almost any software I can think of has different processes for testing/validating changes depending on impact/priority.

e.g. I'm typing this on Firefox, which has a much different process for point release vs their 4-week release cycle.

Reply on news.ycombinator.com