5 ms·

Can you post on hn when the statement that reads like, "btw don't use this package if you're not cool with breaking changes every four days" leaves your docs? I

by trhr 4y ago

Can you post on hn when the statement that reads like, "btw don't use this package if you're not cool with breaking changes every four days" leaves your docs? I pretty much immediately decided I wasn't cool with that, even though bevy looks like a really interesting project.

sho_hn 4y ago
It's sort of a cultural tradition in the Rust community to link to interesting or potentially more stable alternatives in READMEs.
- trhr 4y ago
  https://bevyengine.org/learn/book/introduction/ https://bevyengine.org/learn/book/introduction/ The problem is that "the prototyping phase" isn't a real phase, and this doesn't specify if breaking changes will occur between major, minor, or patch versions. It gives developers no guidance of what semver to track based on their own willingness to endure breaking changes. Using a library that still can't tell you that is just asking for trouble.
  - nicoburns 4y ago
    > 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.
  - cmeacham98 4y ago
    https://semver.org/spec/v2.0.0.html#spec-item-4 https://semver.org/spec/v2.0.0.html#spec-item-4
    - trhr 4y ago
      I'm not saying they're breaking the law and should be arrested, I'm saying if they're breaking shit in patch release, even on v0, I refuse to touch it until v1. If you're not breaking shit in patch releases, I'll touch v0 and pin to a minor. People can run anything they want however the fuck they want, I just won't use it. How's that?
      - spoiler 4y ago
        FWIW, I've been tinkering with Bevy since like 0.6 I think, and don't remember many (if any?) patch breaking changes. I did skip 0.7 since I remember upgrading from 0.6 to 0.8 directly, though. The minor jumps are sometimes very small changes, sometimes giant ones (but alas, it's still a 0.x project, so I got not qualms)
      - cmeacham98 4y ago
        You said > doesn't specify if breaking changes will occur between major, minor, or patch versions What I'm telling you is that it _does_ specify that: by using a 0.x.y version they are explicitly specifying that breaking changes can occur between _any_ version. If you don't want to use Bevy because of that, then that's fine.
        trhr 4y ago
        But you've just nailed the problem: this is NOT the convention used within Rust. In Rust, 0.x.y would treat .y as NON-BREAKING, BACKWARDS-COMPATIBLE changes. I don't think I'm stepping beyond the pale of reasonable engineering when I suggest that a package in the Rust ecosystem that doesn't follow the Rust semver guidance -- and doesn't EXPLICITLY STATE that they don't follow the Rust semver guidance -- is a library I won't touch. The fact that there's so much confusion on this thread about what their semver policy actually is shows exactly why it should be stated upfront and not masked behind a generic "stability warning."
  - IceSentry 4y ago
    Bevy and rust in general uses semver with a special case for 0.x releases. See https://doc.rust-lang.org/cargo/reference/semver.html https://doc.rust-lang.org/cargo/reference/semver.html > Initial development releases starting with "0.y.z" can treat changes in "y" as a major release, and "z" as a minor release. "0.0.z" releases are always major changes. This is because Cargo uses the convention that only changes in the left-most non-zero component are considered incompatible. The 0.x is essentially used as way to tell people to use at their own risk since it isn't considered stable yet. Using a library like this isn't asking for trouble if you know what you are dealing with and in the context of bevy it currently means a breaking change every 3 months with a blog post and migration guide.
sieabahlpark 4y ago
[dead]
LelouBil 4y ago
Well, it's not even 1.0 yet
nicoburns 4y ago
You can see Bevy's release history here: https://github.com/bevyengine/bevy/releases https://github.com/bevyengine/bevy/releases where you can see that there have historically been releases with breaking roughly every 2 months (although the last one was back in Nov 2022)
- IceSentry 4y ago
  It's more like every >3 months because the .1 release aren't breaking
_cart 4y ago
Cheeky answer: I sure can! And people like it! Real answer: Bevy is already very featureful, but we have a long way to go before we can start making "stable api guarantees". Locking things down right now would prevent us from achieving the best apis we can. We are building the engine in the open and people will naturally still take dependencies on us, even under these constraints. We are very careful about our messaging / provide warnings in the appropriate places. In practice, migrating between versions is generally pretty straightforward and we provide migration guides to help the process. The dust is already settling on some of our APIs / they're starting to feel "stable". Many people (and companies) are happily building real products right now in Bevy (and porting them across versions).
- _cart 4y ago
  Follow up reply: I misinterpreted your question. I thought you were saying "(How) can you post this on HN when you are still unstable". But on a re-read it sounds like you just wanted me to post on HN when we have stability guarantees. I definitely can/will! If that is what you meant, I apologize for the misread (and unnecessary cheekiness).

by trhr 4y ago

sho_hn 4y ago

It's sort of a cultural tradition in the Rust community to link to interesting or potentially more stable alternatives in READMEs.

trhr 4y ago
https://bevyengine.org/learn/book/introduction/ https://bevyengine.org/learn/book/introduction/ The problem is that "the prototyping phase" isn't a real phase, and this doesn't specify if breaking changes will occur between major, minor, or patch versions. It gives developers no guidance of what semver to track based on their own willingness to endure breaking changes. Using a library that still can't tell you that is just asking for trouble.
- nicoburns 4y ago
  > 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.
- cmeacham98 4y ago
  https://semver.org/spec/v2.0.0.html#spec-item-4 https://semver.org/spec/v2.0.0.html#spec-item-4
  - trhr 4y ago
    I'm not saying they're breaking the law and should be arrested, I'm saying if they're breaking shit in patch release, even on v0, I refuse to touch it until v1. If you're not breaking shit in patch releases, I'll touch v0 and pin to a minor. People can run anything they want however the fuck they want, I just won't use it. How's that?
    - spoiler 4y ago
      FWIW, I've been tinkering with Bevy since like 0.6 I think, and don't remember many (if any?) patch breaking changes. I did skip 0.7 since I remember upgrading from 0.6 to 0.8 directly, though. The minor jumps are sometimes very small changes, sometimes giant ones (but alas, it's still a 0.x project, so I got not qualms)
    - cmeacham98 4y ago
      You said > doesn't specify if breaking changes will occur between major, minor, or patch versions What I'm telling you is that it _does_ specify that: by using a 0.x.y version they are explicitly specifying that breaking changes can occur between _any_ version. If you don't want to use Bevy because of that, then that's fine.
      - trhr 4y ago
        But you've just nailed the problem: this is NOT the convention used within Rust. In Rust, 0.x.y would treat .y as NON-BREAKING, BACKWARDS-COMPATIBLE changes. I don't think I'm stepping beyond the pale of reasonable engineering when I suggest that a package in the Rust ecosystem that doesn't follow the Rust semver guidance -- and doesn't EXPLICITLY STATE that they don't follow the Rust semver guidance -- is a library I won't touch. The fact that there's so much confusion on this thread about what their semver policy actually is shows exactly why it should be stated upfront and not masked behind a generic "stability warning."
- IceSentry 4y ago
  Bevy and rust in general uses semver with a special case for 0.x releases. See https://doc.rust-lang.org/cargo/reference/semver.html https://doc.rust-lang.org/cargo/reference/semver.html > Initial development releases starting with "0.y.z" can treat changes in "y" as a major release, and "z" as a minor release. "0.0.z" releases are always major changes. This is because Cargo uses the convention that only changes in the left-most non-zero component are considered incompatible. The 0.x is essentially used as way to tell people to use at their own risk since it isn't considered stable yet. Using a library like this isn't asking for trouble if you know what you are dealing with and in the context of bevy it currently means a breaking change every 3 months with a blog post and migration guide.

sieabahlpark 4y ago

[dead]

LelouBil 4y ago

Well, it's not even 1.0 yet

nicoburns 4y ago

You can see Bevy's release history here: https://github.com/bevyengine/bevy/releases https://github.com/bevyengine/bevy/releases where you can see that there have historically been releases with breaking roughly every 2 months (although the last one was back in Nov 2022)

IceSentry 4y ago
It's more like every >3 months because the .1 release aren't breaking

_cart 4y ago

Cheeky answer: I sure can! And people like it! Real answer: Bevy is already very featureful, but we have a long way to go before we can start making "stable api guarantees". Locking things down right now would prevent us from achieving the best apis we can. We are building the engine in the open and people will naturally still take dependencies on us, even under these constraints. We are very careful about our messaging / provide warnings in the appropriate places. In practice, migrating between versions is generally pretty straightforward and we provide migration guides to help the process. The dust is already settling on some of our APIs / they're starting to feel "stable". Many people (and companies) are happily building real products right now in Bevy (and porting them across versions).

_cart 4y ago
Follow up reply: I misinterpreted your question. I thought you were saying "(How) can you post this on HN when you are still unstable". But on a re-read it sounds like you just wanted me to post on HN when we have stability guarantees. I definitely can/will! If that is what you meant, I apologize for the misread (and unnecessary cheekiness).