3 ms·
I'm not sure what we're arguing about. You say "don't break bugfix releases." I say "don't break bugfix releases." Docs don't say "we don't break bugfix release
by trhr 4y ago
I'm not sure what we're arguing about. You say "don't break bugfix releases." I say "don't break bugfix releases." Docs don't say "we don't break bugfix releases." Instead, docs say "we break all the time don't trust us" instead of "pin to a minor version if you don't want to break all the time."
It's specifically not a question of knowing how the Rust community usually does these things, it's a question of "does this package conform to Rust's semver conventions, the official semver conventions, or something custom?"
The statement, _as its written in the docs_ implies "we do something custom." Whether that's true or not is irrelevant. I read it, interpreted it as a lack of governance or adherence to standards, and moved on. Any professional engineer would do the same.
- laundmo 4y agoyou're right, that warning could be improved as it assumes knowledge of how the Rust community usually does these things.
- IceSentry 4y agoNo, the statement says that there will be frequent breaking APIs, it doesn't make any claim about release strategy. Releasing breaking changes on every 0.minor release perfectly fits in this definition. Making a quick judgement based on an assumption that's provably wrong isn't really the definition of a professional engineer.
- trhr 4y agoTell me you've never had a job without telling me you've never had a job. Not having a release strategy at all is insta-trashcan at any enterprise I've ever worked at.