Skip to content
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

Use release #371

Open
wants to merge 2 commits into
base: main
Choose a base branch
from
Open

Use release #371

wants to merge 2 commits into from

Conversation

nim65s
Copy link

@nim65s nim65s commented Oct 23, 2024

Hi,

The cargo.toml / cargo.lock files use git dependencies, but https://crates.io/crates/zenoh/1.0.0 is out :)

Copy link
Contributor

PR missing one of the required labels: {'breaking-change', 'bug', 'enhancement', 'documentation', 'internal', 'new feature', 'dependencies'}

@fuzzypixelz
Copy link
Member

Hello @nim65s!

I appreciate the thought, but the release workflow for zenoh-python only bumps the version in a dedicated release branch: https://github.com/eclipse-zenoh/zenoh-python/tree/release/1.0.0.

The version in the main branch ought to be X.Y.Z-dev where X.Y.Z is the next planned release. It hasn't been updated yet as the roadmap is still under discussion.

Unless there is anything else to discuss or I missed something, I think we can safely close this pull request.

Copy link
Contributor

PR missing one of the required labels: {'breaking-change', 'bug', 'internal', 'dependencies', 'new feature', 'documentation', 'enhancement'}

@nim65s
Copy link
Author

nim65s commented Oct 25, 2024

Thanks @fuzzypixelz for the answer !
I understand that it was deliberate, so we can discard this PR.

My issue is that I'm trying to publish zenoh & zenoh-python on nixpkgs, and it prefers not to have any git dependencies in Cargo.lock, as this make the computation of a proper hash for sources of the package quite harder.

Would it make sense to integrate this constraint in your release workflow ? Basically I would only need that for the release tag, I understand that afterwards it could make sense to switch back to some development setting.

@Mallets
Copy link
Member

Mallets commented Oct 28, 2024

The Cargo.toml used in the release branch has version = '1.0.0'. It also still keeps git but as explained here it should be ignored.

For packaging then the release branch should be used. main branch will always be synced and aligned with any other main branch.

@fuzzypixelz
Copy link
Member

My issue is that I'm trying to publish zenoh & zenoh-python on nixpkgs, and it prefers not to have any git dependencies in Cargo.lock, as this make the computation of a proper hash for sources of the package quite harder.

Could you elaborate on this? What issues are you running into exactly? Are you using cargo2nix?

As @Mallets pointed out, the Cargo reference has this to say:

It is possible to specify both a registry version and a git or path location. The git or path dependency will be used locally (in which case the version is checked against the local copy), and when published to a registry like crates.io, it will use the registry version.

Perhaps the "local use" coincides with your Nix packaging process, but I'm not sure. If you provide more information about your issue we can better understand what can/should be done.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants