Release!

[tcharding]

Lets release already crew. Software always has bugs, this release will not be bug free, no problem, we can fix them and do another release. The open source software mantra is

Release early release often

Lets release in time for Bitcoin Miami and get Marty and Matt to announce it on the open source stage during live Rabbit Hole Recap show.

@dr-orlovsky can we have your blessing to leave your open rc-fixes out of the initial 0.28 release?

[dr-orlovsky]

I am not against this; just notifying that applying pending RC fixes will require a major version bump, since they are API-breaking.

[Kixunil]

I'm not very happy about rushing release just to get in time for conference. If the deadline was announced earlier I'd be more open to it.

[sanket1729]

I am not against this; just notifying that applying pending RC fixes will require a major version bump since they are API-breaking.

Indeed, I don't mind having this later.

I'm not very happy about rushing release just to get in time for the conference. If the deadline was announced earlier I'd be more open to it.

@Kixunil, there was always an implicit deadline after the RC cycle. We have been on RC cycle for multiple months now. This was indirectly discussed last week in some GitHub comments.

[apoelstra]

I agree with @sanket1729. This is not a surprise deadline. We have had a 0.28 milestone, we had that down to zero PRs at one point, we have had multiple RCs and agreed to punt certain changes until future releases.

I think we should push forward on this release, nowish, and then do another major rev with other Taproot changes.

I also think we should have scheduled releases from now on.

I will post a release PR shortly.

[apoelstra]

#944

[Kixunil]

I'm not sure scheduled releases are that great. Perhaps scheduled feature freezes? I kinda like Debian approach - no known significant bugs may be released. Of course we need discussion what are significant bugs. I'll be happy to discuss.

Things that seem important to me:

• vulnerabilities
• logic bugs that could cause loss of sats or privacy
• API usage hazards
• (forward) compatibility hazards
• misleading documentation or item names (esp. if it can cause loss of sats or privacy)
• unusable APIs (e.g. no public constructor for a type that is supposed to be publicly constructable)

Also highly desirable to have clear, Rust-idiomatic names.

[apoelstra]

Perhaps scheduled feature freezes?

Sure. In my model we'd have a scheduled rc, but then an indefinite period of further RCs while we sorted things out. I think this is effectively the same as a scheduled freeze.

[tcharding]

I like sound of this. What time frame shall we pick, six weeks?

[Kixunil]

Too short to my taste, especially with large changes panned. I'd say at least three months.

[apoelstra]

I like 3 months. Could also get behind 4.

I would prefer 6 but that may be too infrequent for a lot of projects which are trying to use Taproot ASAP.

[tcharding]

What if we went for the rc release after 4 months then if we had a soft target of less than two months for the rc fixes etc. then we'd be doing a release at least every six months?

[apoelstra]

I like it.

[apoelstra]

Closing this because it's not obviously the right place to discuss release scheduling. I think #900 is.

Also we finally did the 4/20 release :)