Proposal for 0.12.0 release

[proski]

I realize that cargo2nix may be getting obsoleted by other tools. However, it's users still can get a better experience. There is a lot of good code in cargo2nix, but it's not on the right branches and not in the right releases.

I maintain an internal fork of cargo2nix that reverts 4 commits that break my company's project:

2ae2f57 (this only breaks cross-compilation)
79cd412
807d916
a2ab864 (those 3 are related and interdependent)

It took me a while (days!) to identify those while also dealing with easily fixable issues (old Rust, attempts to access network, irrelevant warnings etc).

If the recent changes to cargo get into stable, that would put most cargo2nix users in a similar situation, i.e. they would have to maintain an internal fork or switch to another solution (crane, crate2nix etc).

What's wrong with cargo2nix now:

• The development happens on a "release" branch
• Major changes go to a "release" branch
• The branch is not even named properly, it should be release-0.11
• Very different revisions of cargo2nix call themselves 0.11.0

This could be done to mitigate the situation without spending too much time:

• Copy the release-0.11.0 branch to main that becomes the main branch for development
• Apply outstanding simple PRs to the main branch
• Create a new release-0.12 branch based on the v0.11.0 tag
• Cherry-pick all changes from main except the commits I mentioned
• Make a new release, v0.12.0
• Use the release-0.12 branch only for simple changes cherry-picked from main

[proski]

One more thing. The main branch should be linearized before being added to the repository by rebasing release-0.11.0 on top on v0.11.0. It's painful to bisect issues on a heavily branched tree.

The repository should be configured to only allow fast-forward, no merges.

[proski]

Thinking more about it, the problematic commits should not go to the main branch, they should go to PRs and stay there until they are fixed.

[proski]

Done so far:

• Created the main branch with all commits from release-0.11.0 except the problematic ones
• Created 2 PRs for the problematic commits, added my minor fixes to them
• Re-targeted my unapproved PRs to the main branch
• Created the release-0.12 branch identical to main for now

My private fork of cargo2nix is identical to the main branch and have been used on a large multi-user project for months. That involves cross-compilation, workspaces and using relative paths with .. to libraries. I'm quite confident that the code is good for the current stable Rust.

What needs to be done:

• main and release-0.12 should be protected.
• main should become the default branch.
• there should be a clear message that the project is in maintenance mode
• (optional) the outstanding PR should be reviewed and merged
• release version 0.12.0 (it doesn't have to be perfect, we can always do 0.12.1)

[psionic-k]

Do you need extra rights on this repository?

[proski]

I cannot change the default branch and protect branches. Please either do it for me or give me permission to do it. It's not good to have an unprotected main branch.

I don't think I can make releases, but we are not at that point yet.

I cannot merge PRs without approval. That's OK for now, as I'm getting approvals quickly. It could be a problem if everyone else walks away and stop looking at the PRs.