5 ms·
Seeing a project on a pretty high major is a positive signal to me. It tells me that they understand semver and know how to use breaking changes. Of course if a
by kall 5y ago
Seeing a project on a pretty high major is a positive signal to me. It tells me that they understand semver and know how to use breaking changes. Of course if a project is just very stable and sticks to 1.x, that‘s great too. I don‘t consider that a negative signal. Purely anecdotally, 3 is the scariest version number to me.
React sets a pretty good example here: react 17 is the most boring release in the world. The react team are not bad API designers that made 17 major mistakes. They may be the most considerate and pleasant API designers in all of frontend, actually.
React Native is on 0.64.4 (?) not because it‘s unfit for production but because they know the level of guarantees they can make about version upgrades is zero.
- bpodgursky 5y agoI've also seen projects on like 124.0.0 just because they don't care about semver and just release major versions every time.
- eurasiantiger 5y agoStill a better release numbering scheme than going by year and update.
- nonameiguess 5y agoThe Naval Research Lab releases their radar processing algorithms package for geointelligence products by build number. We always got a kick out of a new delivery updating us from nrltools-3872 to nrltools-4923 or something.
- CJefferson 5y agoIt's also easy to get to 124 if you are a library with very few private functions -- in that case almost any change breaks ABI.
- dexterhaslem 5y agoyes but didn't react do a big jump? like 0.13 -> 14.0 or such many moons ago. at any rate agree with the point
- mcaruso 5y ago0.x releases are also major versions according to semver, just pre-stable. So many people were referring to React 0.x releases as "React x" that they just bumped it straight to version x.
- kstenerud 5y agoUnfortunately, go has broken semver, so all of my go projects now stay at 1.x.y, with x being the "major" version (breaking changes) and y being the "minor" version (non-breaking changes) and the 1 sitting there useless. I suspect that many others do the same, so for go projects the x version field is the one to pay attention to. Although TBH it's not all bad; all anybody has ever really cared about is "are there breaking changes or not?"
- devin 5y agoTo me it's a signal that if I rely on this software in my own projects, I am signing up for an upgrade treadmill.
- kyrofa 5y agoAmen.
- travisjungroth 5y ago2 seems to be the final number for business stuff. CustomerReportv2 or UserModel2 or /api/v2/ are wildly more common than 3 IME.
- unilynx 5y ago“That major update where we redid the whole API turned out to be so unexpected painful, we’re never doing that again” once for every business
- kall 5y agoI think it goes something like 1: We made something that we think is good, but we don‘t know if others will and how they will use it. We tested it well in one scenario but not much else. 2. Now we actually understand how people use this and why they like it. We have collected all of their biggest problems and it‘s time to fix them. 3. Everyone loves our thing and it‘s very productive for them. That must mean we‘re geniuses. Let‘s fuck around and change the world. 4, 5, 6… Both we and our users understand that sometimes we need to make a breaking change. They already went through the terrible 2->3 migration so every other upgrade will be fine by comparison. In an enterprise context there are probably enough layers that keep everyone in check so the step 3 where you run wild with your ideas never happens.