Periodic Release cycle

[sanket1729]

Many bitcoin projects have periodic release cycles. I think we should consider having a regular release every N months/weeks. Any thoughts/opinions.

PROs:

• A fixed timeline helps in guiding/selecting PRs that should go in a release. There is no scope creep
• Downstream projects benefit from knowing when the release is coming out and would have relatively small things to update

CONs:

• May end up being more effort than it already is. I think we can take inspiration from c-lightning in marking release captions for each release to balance the load. The role of the captain is to move things in and around the project to make the timely release happen.

This may be too early for the project now to have commitments from maintainers to work towards a fixed timeline.

[dr-orlovsky]

Well, since I am managing my working scopes and tasks myself and all my projects are ultimately depend on rust-bitcoin progress I can take certain commitments to spend sufficient amount of time regulary in periods when I have to act as a release capitian.

[tcharding]

Some relevant discussion was had, starting at the comment: #941 (comment)

[apoelstra]

Should we schedule a feature freeze (and maybe rc) for 8/20?

cc @Kixunil

[Kixunil]

I believe we wanted to do a quicker release now with MSRV bump+edition change? I'm fine with either.

[sanket1729]

I would like a quicker MSRV release.

[apoelstra]

SGTM.

[tcharding]

Two weeks

[tcharding]

Just checking we are all on the same page. Excluding this upcoming release (quick MSRV release) we will move to scheduling a release-candidate to be released after six months. Assuming it takes us more than a week to get the 0.29.0 out the door that means 0.29.0 in August and 0.30.0-rc1 in Februrary 2023.

[Kixunil]

I'm rethinking this again. Thoughts:

• serde releases super-often, ~every few commits
• There's no extra testing or other significant work on release, just increase version, update changelog, publish crate; could be automated (maybe with cargo release)
• Frequent releases are nicer for people who need new features and may motivate contributions ("I will not wait long for release so instead of hacking it in my code, I can make a PR and start using the new feature soon")
• I question the value of RC releases since we can just do a point release. cargo update is nicer than editing Cargo.toml anyway.
• There's a significant difference between this crate and serde: we're not stable yet.
• Breaking releases are more annoying so it's probably better to group breaking changes.

Suggested alternative:

• Have additional minor-changes-0-$major branch that branches off master after each release of 0.$major.0
• All new stuff still goes to master
• If a change is not breaking API and can be applied cleanly to minor-changes-0-$major it's cherry-picked with the help of automated tooling (I'm willing to write it.)
• If the change is not breaking and doesn't apply cleanly, the author or anyone interested is allowed to make a second PR to minor-changes-$major manually resolving the conflicts
• No change will stay unreleased in minor-changes-0-$major for longer than one week
• Security vulnerability or critical bug fixes are released immediately after merging
• Releasing of master is goal-based: we decide what breaking changes we want to make and do them, once they are done we release. If other breaking changes get introduced by chance it's OK, they just have to be self-contained within a PR.

[DanGould]

I get excited for a release. More frequent would be awesome. What's the bottleneck on releasing everything that gets merged to master? major/minor disambiguation? couldn't that be remedied by merging only when it's ready to release and so the interface is thought through that end? release notes?

[Kixunil]

Long-outstanding PRs are very bad for reviews so I want to avoid that. I'm pretty sure there will be a bunch of API breaks because this crate and the rest of the ecosystem is currently very far from idiomatic. :( See the 1.0 label

[apoelstra]

@DanGould couple bottlenecks:

• Releasing requires another PR to add a version bump, which has to go through CI etc and then I need to run tests and do a sign/publish/tag cycle
• As soon as one breaking change is in master then we would need to do a major release, and we don't want to do a zillion major releases, especially if we might have to backport stuff (though automated tooling could maybe help here).

[tcharding]

What's the thoughts on @Kixunil's idea to have a point branch for non-breaking changes and do point releases often/weekly? What's your current position on the next release @apoelstra please, just so I, and others, know what we are working towards?

[apoelstra]

I don't think we have any big features that we want to get in ... so my feeling is that the next few releases probably should focus on getting to 1.0. The next one in particular I'd like to be about rearranging modules and maybe crate smashing. What do others think?

[tcharding]

Yep that's the work I had in mind, are we going to commit to a time frame or just get the work done?

[Kixunil]

I think I agree for this one. We plan significant refactoring changes, so backporting would be harder than usual. But wouldn't be against small additions if people need them and can't NIH them for the time being.

[tcharding]

Rust version 0.31.0 scheduled for release August 2023 team?

We were supposed to release in Feb but were a month late, the question is, do we aim for 6 months from now or every six months irrespective of lateness i.e., Feb and August every year?

[apoelstra]

I'd like to do "every 6 months regardless of lateness", though I'd be willing to slip from "unspecified date in Feb" to "March 1".

FYI I have a child due to be born on Sep 1 so I'm gonna be AWOL around the next scheduled date, sorry :). It may make sense to slip our schedule another month because of that.

[Kixunil]

I would rather release sooner than later (at least the upcoming one). Would July be OK for you?

[apoelstra]

Yep, for sure -- so what if we did a pre-release on May 1, and a real release in place of the second pre-release, on July 1?

[tcharding]

Hell yeah! (for the new child and the early release :)

[junderw]

Your newborn child's name will be v0.31.0 and we'll tag the release Saori or Satoshi depending on the release's gender reveal...

🎉 congrats!