4 ms·
I think the author discounts the cost of "there are only a few users, so it's not a big deal to have breaking changes". I think stability and the backwards comp
by rgoulter 7y ago
I think the author discounts the cost of "there are only a few users, so it's not a big deal to have breaking changes". I think stability and the backwards compatibility of a tool are important considerations to make in "is this worth using?".
If a tool has a large community of usage, breaking compatibility affects a large number of users.
If the tool doesn't have a large community, then a lack of stability means there's risk the tool won't in-future support current use cases, or that I'll have to spent much more time maintaining my use of it than with 'boring' tools.
It's fine for a tool in v0.x to have breaking changes. I think not supporting stable versions of a tool would make it hard to retain users in the long run, though.
- TeMPOraL 7y agoHere's a counterargument: if a tool starts developing userbase, it's likely to have even more users in the future. Up to a point, the more users it has, the more it will have. So a breaking change while the userbase is still relatively small can be justified on the grounds of making things better for a larger number of soon-to-be users.
- jon889 7y agoI agree. People complain that Swift changed too much in the earlier versions but I'm glad it did and I'm kind of sad that it's slowed down now and there are things I wish could be changed but can't. Yes it was a bit of a pain but there were migration tools that helped. And that pain is long since forgotten.