Replies: 7 comments 7 replies
-
|
I am not against this; just notifying that applying pending RC fixes will require a major version bump, since they are API-breaking. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
Indeed, I don't mind having this later.
@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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
|
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:
Also highly desirable to have clear, Rust-idiomatic names. |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
|
I like sound of this. What time frame shall we pick, six weeks? |
Beta Was this translation helpful? Give feedback.
-
|
Too short to my taste, especially with large changes panned. I'd say at least three months. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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? |
Beta Was this translation helpful? Give feedback.
-
|
I like it. |
Beta Was this translation helpful? Give feedback.
-
|
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 :) |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
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?
Beta Was this translation helpful? Give feedback.
All reactions