Open MarcoIeni opened 6 months ago
Thanks for opening this. I am interested in working on it.
In case it is helpful, on the CLI version, there is a relevant flag --registry-project-manifest
flag.
The explanation for that flag is:
Path to the Cargo.toml contained in the released version of the project you want to update. If not provided, the packages of your project will be compared with the ones published in the cargo registry. Normally, this parameter is used only if the published version of your project is already available locally. For example, it could be the path to the project with a `git checkout` on its latest tag. The git history of this project should be behind the one of the project you want to update
Hey @jdidion do you still work on this? No pressure of course. I'm asking because if you are no longer working on this, maybe someone else wants to pick the issue :)
Hi Marco, yes I've been working on it slowly. Just created a draft PR so you can see the progress https://github.com/MarcoIeni/release-plz/pull/1227. Tl;dr right now I have:
RepoVersions
enum which has variants for a single package or multiple packages (they are different because of the way the git tags are formatted)repository_packages: Option<&RepoVersions>
parameter to all the functions in next_ver.rs
where it is neededNow I'm looking at how to actually implement get_diff
for a git-only package and I'm thinking I need some higher level interface which can abstract whether the package information is coming from the registry or the git repository. Happy to have some input on what you think is the best approach (trait, enum, or something else).
Thanks @ozgunozerk I'll take a look at that option. Maybe the implementation of that option will hint at how I should implement git-only.
So far the PR looks great!
I'm thinking I need some higher level interface which can abstract whether the package information is coming from the registry or the git repository
Yes, I think that would help.
Happy to have some input on what you think is the best approach (trait, enum, or something else).
I prefer enum because they are simpler, but whatever it works for you it's fine :)
I would say, let's not overthink it. First let's get it working, and we can refine later :)
Seems like this issue is stale again. I can take over, but what I had in mind overwrites some work @jdidion already did. If he does not have enough time to continue on this, I already have a good understanding of the repo and the issue, and I can take over. What are your thoughts @MarcoIeni?
Hey Özgün, great to see you're still interested in working on this. Feel free to take over. If you don't want to overwrite work, you can also start a new PR. As you prefer 👍
Motivations
Some people want to use release-plz without publishing on crates.io. We could use git tags as the source of truth.
Solution
git_only
configuration flag at the workspace level, that you can also override for each package. Values:true
orfalse
. False by default.git-only
mode is onpublish = false
in the Cargo.toml ifgit-only
is on for that package.Additional context
Created from the discussion in https://github.com/MarcoIeni/release-plz/issues/590#issuecomment-1519170017 and https://github.com/MarcoIeni/release-plz/issues/1139