Add a "git only" mode

[MarcoIeni]

Motivations

Some people want to use release-plz without publishing on crates.io. We could use git tags as the source of truth.

Solution

• Add a git_only configuration flag at the workspace level, that you can also override for each package. Values: true or false. False by default.
• Disable the error introduced in chore: release #114 if the git-only mode is on
• Make sure to consider packages with publish = false in the Cargo.toml if git-only is on for that package.

Additional context

Created from the discussion in #590 (comment) and #1139

[jdidion]

Thanks for opening this. I am interested in working on it.

[ozgunozerk]

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

[MarcoIeni]

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 :)

[jdidion]

Hi Marco, yes I've been working on it slowly. Just created a draft PR so you can see the progress #1227. Tl;dr right now I have:

• implemented the function to fetch the most recent release tag(s) from the git repository
• created a RepoVersions enum which has variants for a single package or multiple packages (they are different because of the way the git tags are formatted)
• added a repository_packages: Option<&RepoVersions> parameter to all the functions in next_ver.rs where it is needed

Now 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).

[jdidion]

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.

[MarcoIeni]

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 :)

[ozgunozerk]

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?

[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 👍