Release 0.6.0 #218
Release 0.6.0 #218
Conversation
Restioson
force-pushed
the
release-0.6.0
branch
from
0f8498d
to
e091ca7
Compare
Restioson
force-pushed
the
release-0.6.0
branch
from
e091ca7
to
229bef7
Compare
|
@thomaseizinger: I've released from this branch now - can we merge these in? minimal set of changes to get it to work |
| @@ -1,7 +1,11 @@ | |||
| [package] | |||
| name = "xtra-macros" | |||
| version = "0.1.0" | |||
| version = "0.6.0" | |||
There was a problem hiding this comment.
Why does this need to track the version of the root crate?
There was a problem hiding this comment.
Arguably it does not, but I think this is a standard set in other crates - serde and serde_derive seem pegged, as do bevy and bevy_internal/bevy_dylib (and even bevy_input, which is not a dependency of bevy but a core extension crate). askama and askama_derive track eachother in the minor and major version. I would argue it's a bit simpler if we don't have, say xtra 0.8 depending on 0.2 of xtra_macros. At the very least, since we re-export xtra_macros from xtra, any breaking change (while in 0.x) requires bumping xtra alongside xtra_macros. Vice versa is not strictly true but is more likely as the API surface is so small now.
Apologies for doing this without consulting you. I did it without thinking too deeply about it at the time as I'd thought this was just kind of the standard practice. I'll make sure it doesn't happen again
There was a problem hiding this comment.
I guess it does makes things easier while we are in 0.x land and after 1.x, the difference doesn't matter too much :)
For the future, I'd suggest to not release from branches but only after they are merged. With squash merging, the commits in the branch never land on master, meaning you can't have a tag now that directly corresponds to the released code. |
|
Are you okay to just rebase merge this in to master then? Thanks for the tip, I didn't anticipate that. |
Yes I think this would be a good idea! :) |
No description provided.