Conversation
…ous/bevy_tween into event_emitting_tween_tag
There was a problem hiding this comment.
Nice. Though, I'll need you to remove any related changes regarding versions and semver and be done in a separate PR. This is to make it easier to audit in the future. It can be a slight issue when we try to resolve issue related to changed version and apparently that's done within a PR that adds a single feature with zero mention of changed version.
| @@ -1,8 +1,9 @@ | |||
| # Changelog | |||
|
|
|||
| ## Unreleased - XXXX-XX-XX | |||
There was a problem hiding this comment.
Replacing Unreleased - XXXX-XX-XX into a specific date and version is only allowed within release PR. Also, where's the changlong for v0.10.0? What did we do then?
There was a problem hiding this comment.
All we did for 0.10 was update to Bevy 0.17
I'll make a patch commit
| ## Unreleased - XXXX-XX-XX | ||
| ## v0.10.x - 2025-12-28 | ||
|
|
||
| - Migrate to Bevy 0.17.2 |
There was a problem hiding this comment.
Note that bumping patch version does nothing when we don't need it. If for some reason, a user must use a specific bevy version older than this for some reason, this can cause incompatibility for no gain, but it's probably a non-issue for bevy project. Also, this should be done in a separate PR.
| [package] | ||
| name = "bevy_tween" | ||
| description = "Flexible tweening plugin library for Bevy" | ||
| version = "0.10.0" |
There was a problem hiding this comment.
This should only be done within a release PR. Also, why are we updating patch version?
There was a problem hiding this comment.
To be able to release a new version of the helpers crate (since crates have to be built upon stable crate versions, can't just route it to main)
There was a problem hiding this comment.
Patch version is used for bug fixes. This is unrelated to releasing the crate.
There was a problem hiding this comment.
So should we release an entirely new version for two lines of code?
Sounds absurd
There was a problem hiding this comment.
Yes, that's how semver works. You can read the semver specification on why we need to increment the minor version. Also, releasing it as patch is still an entirely new version. Semver is used to state project compatibility and how the downstream users should deal with them.
It will be very surprising for user of our crate to notice that, an entirely new component, is being inserted into their runtime from just updating their crate to the newer patch version.
Semver DOES NOT implies how big of a changes a crate has made between major, minor, and patches. (even though the major version seems to be used for marketing nowadays...) There could be thousand line of bug fixes and that can still be within patch version.
There was a problem hiding this comment.
Uhh, not yet. Bumping crate version should also be done in a separated PR. The same withing updating Unreleased - XXXX-XX-XX changelog.
2 participants
Adding a marker component
EventEmittingTweento all registered event-emitting tweens for ease of querying