3 ms·
>In a versioned world, you can release your change as a new version, and allow your users to self-select Repeat this process multiple times and you end up with
by perfunctory 8y ago
>In a versioned world, you can release your change as a new version, and allow your users to self-select
Repeat this process multiple times and you end up with configuration/settings hell. Been there done that. It's not black and white but "trampling over the 0.1%" could be a sensible business/architectural decision. For example how do you imagine "google maps" users selecting when/how to migrate?
- whack 8y agoI was referring only to static dependencies, like Guava for example. Static dependencies don't require ongoing "upkeep", so you really should allow your users to use an older version of your library/code, if that's what they really want to do. When it comes to live services that you're actually running on a daily basis, like Google maps, forcing users to migrate makes a lot more sense.
- perfunctory 8y agoI see. I guess static dependencies are not as prone to ongoing upkeep as services, but they are not totally immune. Think Heartbleed.
- whack 8y agoJust because your older versions are available to users, doesn't mean you have to continuously maintain them. For example, I know plenty of teams still using Java 7, even though Oracle has EOLed it. The teams know the risk that they are taking, and have the flexibility to decide when they want to migrate to a newer version, and that's how it should be. I would never want to live in a world where Oracle can force me to migrate to Java 10 within a day of release.
- googlemike 8y agoWhat do you define as a static dependency?
- deleted 8y ago[deleted]