3 ms·

> this doesn't specify if breaking changes will occur between major, minor, or patch versions The entire Rust ecosystem works on a model of breaking changes fo

> this doesn't specify if breaking changes will occur between major, minor, or patch versions The entire Rust ecosystem works on a model of breaking changes for 0.x version happening in minor but not patch releases. In fact, I'm struggling to think of any software project that intentionally releases breaking changes in patch releases.

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 ago
  you're right, that warning could be improved as it assumes knowledge of how the Rust community usually does these things.
- IceSentry 4y ago
  No, 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 ago
    Tell 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.

3 ms·

> this doesn't specify if breaking changes will occur between major, minor, or patch versions The entire Rust ecosystem works on a model of breaking changes fo

by nicoburns 4y ago

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 ago
  you're right, that warning could be improved as it assumes knowledge of how the Rust community usually does these things.
- IceSentry 4y ago
  No, 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 ago
    Tell 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.