Initial release (v.0.1.0)
stefano-garzarella opened this issue · 9 comments
In the next few days, we should start releasing the first version of the binaries available in this workspace.
I was starting to look at the process and have a few questions I would like to discuss:
- should we create a tag for each different crate (e.g. vhost-user-vsock-v0.1.0, etc.) or a single tag (e.g. v0.1.0)?
- do we have to create a crate in crates.io for each binary (I think so, but I don't know if there is a way to publish them all together)
- when do we want to stop development and tag the first versions?
Next Friday I would like to give it a first try, but since the workspace is big, maybe we should define a roadmap together.
@mathieupoirier @stsquad @vireshk @Ablu WDYT?
I'll try to document all the steps and create a documentation that we can follow each time. Complementary to https://github.com/rust-vmm/community/blob/main/docs/crate_release.md
Thanks for opening this!
- should we create a tag for each different crate (e.g. vhost-user-vsock-v0.1.0, etc.) or a single tag (e.g. v0.1.0)?
@vireshk and me discussed this on IRC and thought that being able to do independent releases for crates may be neat. But I got no particulary strong opinion on this.
- do we have to create a crate in crates.io for each binary (I think so, but I don't know if there is a way to publish them all together)
I think so too. We probably also would not want to impose dependencies of one crate onto another. If we do not want this, we would have to restructure this project to be a single crate/package too.
- when do we want to stop development and tag the first versions?
I think we would be fine to release things without making stronger stability guarantees than current master... We mostly care about having an initial version out so that we can set up packaging recipes and push them upstream. Whether that version is particularly stable or not, we do not really care at the moment. So from our point of view, the sooner the better. Once we got the process in place, doing a bugfix release hopefully should not be as scary?
Thanks for opening this!
- should we create a tag for each different crate (e.g. vhost-user-vsock-v0.1.0, etc.) or a single tag (e.g. v0.1.0)?
@vireshk and me discussed this on IRC and thought that being able to do independent releases for crates may be neat. But I got no particulary strong opinion on this.
Yep I agree, especially with the current organization of the repository.
- do we have to create a crate in crates.io for each binary (I think so, but I don't know if there is a way to publish them all together)
I think so too. We probably also would not want to impose dependencies of one crate onto another. If we do not want this, we would have to restructure this project to be a single crate/package too.
Right. That would simplify release management and also tags (we would have the same version for every binary). But less freedom to update only specific binaries, though. I don't have a strong opinion, let's see how this release cycle goes and then see.
- when do we want to stop development and tag the first versions?
I think we would be fine to release things without making stronger stability guarantees than current master... We mostly care about having an initial version out so that we can set up packaging recipes and push them upstream. Whether that version is particularly stable or not, we do not really care at the moment. So from our point of view, the sooner the better. Once we got the process in place, doing a bugfix release hopefully should not be as scary?
Agree, thanks for your thoughts!
And I am fine with whatever you guys come up with :)
I think there is a benefit to having a single repository so common patterns can be recognised and refactored over time. Other than that I think v0.1.0 is a stake in the ground and we can evolve the release criteria as we go.
I think there is a benefit to having a single repository so common patterns can be recognised and refactored over time. Other than that I think v0.1.0 is a stake in the ground and we can evolve the release criteria as we go.
@stsquad yep, absolutely the single repository helps. Our discussion was about how to organize the repository:
- a single crate with multiple binaries
- a workspace with multiple crates, one for each binary (current state)
A single crate definitely simplifies our releases because we can use one tag for everything and release everything together.
Whereas, using multiple crates is more time-consuming, but it allows us more flexibility since we'll handle the tags separately for each different binary.
1. a single crate with multiple binaries 2. a workspace with multiple crates, one for each binary (current state)A single crate definitely simplifies our releases because we can use one tag for everything and release everything together. Whereas, using multiple crates is more time-consuming, but it allows us more flexibility since we'll handle the tags separately for each different binary.
I can absolutely imagine there will be times we want to release a new version of single binary rather than churning a new release across the board.
I can absolutely imagine there will be times we want to release a new version of single binary rather than churning a new release across the board.
Yep, definitely. So that's how we start for now, I think we can always change in the future if we find it's too time-consuming.