Adopt Rust like Release model

[canewsin]

Rust and other Most of the languages and frameworks follow, a release model having seperate branches for release types for stable builds -> stable branch, beta for beta branch.

Why this is important ?
Since rust-libp2p is in wip, most of the wip/early projects and some projects and depends on master branch, for every commit added by the community, builds are having issues, as i previously opened issues like "dependency conflicts" and "api incompatibilities" for example.

Results:
When we have this type of segregation, at least we have buildable branches for each release type.

[mxinden]

I am not quite sure I follow. How would that branching model be reflected in semver versions on crates.io?

at least we have buildable branches for each release type.

Our CI enforces that there is at least one combination of all dependency versions that compiles. I don't see how the above suggestion would prevent version conflicts on a general level.

[canewsin]

@mxinden I will look into crates issue further. But for now, this will help atleast for project that rely directly on github repo.

libp2p = {git = "https://github.com/decentnetwork/rust-libp2p.git", branch = "relay-v2-mod", features = ["tcp-tokio"]}

here we can replace branch with "beta" for eg.

[thomaseizinger]

@mxinden I will look into crates issue further. But for now, this will help atleast for project that rely directly on github repo.

libp2p = {git = "https://github.com/decentnetwork/rust-libp2p.git", branch = "relay-v2-mod", features = ["tcp-tokio"]}

here we can replace branch with "beta" for eg.

Not meaning to be rude but if you are depending on work-in-progress branches then that is sort of on you if they fail to compile etc

We don't really follow a rapid iteration model in rust-libp2p.

What I would suggest is that you fork rust-libp2p and create yourself more stable versions of WIP stuff if you need it earlier. Then you are less affected by changes to these branches and can "promote" them into your own beta / whatever branch when you need.

But in general, when you are depending on WIP branches, you are buying into less stable code. Want more stable code? Only use released versions.

[canewsin]

@mxinden currently doing this, I prefer this type model because, currently there is boom in p2p market space as well as rust usage, obviously developers tend to rely on libp2p. there are various prs ready to be merged but still on hold for some reasons, these might be released to such branches, so that we can have testing for free before releasing them to stable branches.

[thomaseizinger]

there are various prs ready to be merged but still on hold for some reasons,

These "reasons" for example include testing and/or reviews by other maintainers / collaborators to make sure the code works and does what is meant to be doing.

My advice from above still applies. Fork rust-libp2p and merge the branches you want to use in your own fork, then depend on that. That is essentially equivalent to what you are asking us to do. That will obviously come with some maintenance overhead on your end but that is the price of depending on bleeding-edge stuff.

I doubt we ever want to give out any stability guarantee of non-released code. That would likely slow things down more instead of speed them up.

[dvc94ch]

I think it's a legitimate idea to merge large features sooner behind an unstable feature flag instead of having feature branches arround for long periods of time. It has the advantage that small PR's are easier to review.

[thomaseizinger]

I think it's a legitimate idea to merge large features sooner behind an unstable feature flag instead of having feature branches arround for long periods of time. It has the advantage that small PR's are easier to review.

I agree in principle but in practice, this might be hard to achieve. If the feature changes existing code (like "concurrent dial" did for example), having a feature flag would mean keep both old and new around so we can switch back and forth. That sounds like a maintenance hell to me 😅

[thomaseizinger]

Closing in favor of some discussions in #2902.