-
Notifications
You must be signed in to change notification settings - Fork 15
Add EventEmittingTween tag to event tweens #72
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from all commits
22778a3
3bba016
cb4c794
9e2e9e5
40901b7
b9f62da
6df396e
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -2,7 +2,11 @@ | |
|
|
||
| ## Unreleased - XXXX-XX-XX | ||
|
|
||
| - Migrate to Bevy 0.17.2 | ||
|
Owner
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 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. |
||
| - Add `EventEmittingTween` tag to event emitting tweens, for ease of querying no matter their data type | ||
|
|
||
| ## v0.10.0 - 2025-10-08 | ||
|
|
||
| - Migrate to Bevy 0.17 | ||
|
|
||
| ## v0.9.1 - 2025-07-15 | ||
|
|
||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,7 +1,7 @@ | ||
| [package] | ||
| name = "bevy_tween" | ||
| description = "Flexible tweening plugin library for Bevy" | ||
| version = "0.10.0" | ||
|
Owner
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This should only be done within a release PR. Also, why are we updating patch version?
Collaborator
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 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)
Owner
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Patch version is used for bug fixes. This is unrelated to releasing the crate.
Collaborator
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. So should we release an entirely new version for two lines of code?
Owner
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 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.
Collaborator
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Alright, done
Owner
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Uhh, not yet. Bumping crate version should also be done in a separated PR. The same withing updating |
||
| version = "0.11.0" | ||
| edition = "2024" | ||
| authors = ["Multirious", "Rabbival"] | ||
| license = "MIT OR Apache-2.0" | ||
|
|
@@ -18,12 +18,12 @@ resolver = "2" | |
| # See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html | ||
|
|
||
| [dependencies.bevy] | ||
| version = "0.17.2" | ||
| version = "0.17.3" | ||
| default-features = false | ||
| features = ["std"] | ||
|
|
||
| [dependencies.bevy_math] | ||
| version = "0.17.2" | ||
| version = "0.17.3" | ||
| default-features = false | ||
| features = ["curve"] | ||
|
|
||
|
|
@@ -41,14 +41,14 @@ features = ["std"] | |
|
|
||
| [dependencies.bevy_lookup_curve ] | ||
| version = "0.10.0" | ||
| optional = true | ||
| optional = true | ||
|
|
||
| [dev-dependencies] | ||
| bevy-inspector-egui = "0.34.0" | ||
| rand = "0.9.1" | ||
|
|
||
| [dev-dependencies.bevy] | ||
| version = "0.17.2" | ||
| version = "0.17.3" | ||
| default-features = false | ||
| features = [ | ||
| "bevy_window", | ||
|
|
@@ -60,7 +60,7 @@ features = [ | |
| "png", | ||
| "bevy_sprite_render", | ||
| "bevy_post_process" | ||
| ] | ||
| ] | ||
|
|
||
| [build-dependencies] | ||
| rustc_version = "0.4.1" | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Replacing
Unreleased - XXXX-XX-XXinto 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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
All we did for 0.10 was update to Bevy 0.17
I'll make a patch commit