Next release target: new major? #3418
Replies: 6 comments 5 replies
-
I think the correct choice depends on how much developer and external
interest there is—and whether the options would help or hurt Dogecoin in
the long run. My view is that if there is more developer interest we should
try for 1.15 first, and if there is less we may benefit from directly
pushing for 1.21.
…On Fri, Feb 16, 2024, 13:08 Old Dip Tracker ***@***.***> wrote:
In less than 2 months, the final year of regular LTS support for Ubuntu
Focal begins, which we use for builds and releases. Although I don't mind
upgrading the build system, every two years a lot of people spend a lot of
time "down", because we're facing a dysfunctional CI, broken gitian
scripts, have an increasing set of patches to maintain for backward
compatibility, and are unable to upgrade some pinned dependencies.
I have previously mentioned that we need to have a functional new major
release sooner rather than later, because of the difficulty of keeping
outdated dependencies up-to-date. The target for this new major has for the
last 3 years been 1.21.
However, we lack so much momentum on that effort for 2 years now, that (a)
I don't think we'll be ready with a first release candidate before April,
and (b) it's already a suboptimal target in terms of getting the latest
Bitcoin Core base release, as a lot has been improved in their 5 subsequent
releases.
Instead of developing improvements and new features into 1.14, it's also
possible to base a 1.15 off 1.14.7 once it's released, and be able to get
rid of some constraints, to focus on more important work:
- Get rid of gitian as a binary baking system because that is now
unmaintained
- Drop support for ancient OS versions
- Remove Openssl and BIP70 functionality to defend against external
vulnerabilities
- Upgrade Qt to an actively maintained version
- Refactor and clean up more, because some of the code is terrible to
read
- Focus on features and performance, instead of compatibility
1.14.x would remain maintained for bug- and security fixes, but not touch
any functionality on it anymore. This would be comparable to an "extended
support" phase, where for a limited time any bugfixes can be backported,
and then could be archived as EOL.
Perhaps the biggest upside would be that this is by far the least risky
means to do major updates, as this approach doesn't require throwing away
years of work on stabilization and bugfixing. The downside of a
construction like this would be that there will be more distractions from
1.21 than there already are.
This is just an idea I've been playing with. I'd appreciate learning
everyone's thoughts on this - please do not hesitate to share your view.
—
Reply to this email directly, view it on GitHub
<#3418>, or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AHOXLYHUSWVRQB5KA2MB4TLYT6OA3AVCNFSM6AAAAABDMN7TFCVHI2DSMVQWIX3LMV43ERDJONRXK43TNFXW4OZWGIZDONBSGU>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
That makes more sense, good to know you've considered it! I'm sure everyone
is happy to help either way.
…On Fri, Feb 16, 2024 at 2:14 PM Old Dip Tracker ***@***.***> wrote:
It's good you mention this. I have a slightly different perspective on
that rationale though:
to "push" 1.21, i.e. get it ready for a first RC in 2-3 months, we need
more experienced developers. I can push it by myself on my own repo, but
then it's all but guaranteed to see another fork-like fiasco, potentially
worse than the one from 1.10 that I just documented last month. Doing 1.15
would give people the opportunity to get more comfortable with the code and
protocol as-is while touching it, without having any real blockers
up-front. 1.21 on the other hand is one serial stream of risky must-have,
blocking patches to get a new base.
I guess I'd put your rationale in reverse because of this: with less
developer experience and availability, 1.15 is the better choice from where
I'm sitting: it creates a safer environment for people to learn and grow
based on a well known and supported codebase than we'd have when everyone
has to learn all of Bitcoin and all of Dogecoin, and understand each
difference. This allows for developer-development much better than
preforming a high risk refactor of an undocumented, untested patch set.
I also think that we could even do the CSV soft-fork on a subsequent
1.15.x - it's already sitting in 1.14 too - so even protocol development
doesn't have to be stalled. Just the big protocol enhancements will not be
easy to do on there. That would give younger developers a chance to get
experience with softfork processes.
—
Reply to this email directly, view it on GitHub
<#3418 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AHOXLYHQDVP7BML23VGIF7DYT6VZFAVCNFSM6AAAAABDMN7TFCVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4DIOJWGI3DE>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
My initial reaction is support for 1.15. In addition to your reasoning, I think it's more likely to get us on a more frequent release cadence, which I always like. |
Beta Was this translation helpful? Give feedback.
-
Couple questions about this.
I like this, but would it spread maintainers too thin?
Is this a big job? What does it entail? |
Beta Was this translation helpful? Give feedback.
-
Following. Agree with the reasoning in support of 1.15 thank you for expressing consideration of newbs like me 🙏Sent from my iPhoneOn Feb 16, 2024, at 1:07 PM, Old Dip Tracker ***@***.***> wrote:
I like this, but would it spread maintainers too thin?
If we base 1.15 off the latest 1.14 release, then every one of these types of bug fixes for 1.14 would also apply to 1.15. So it's as simple as fixing and testing it on 1.15, then opening a branch and applying a bunch of patches to backport to 1.14. It's less work than having to maintain all these old dependencies.
Is this [Qt upgrade] a big job? What does it entail?
For current standards of the work done on here, it's one of the bigger ones, yes. But we cannot do it right now on 1.14, and the weeks after weeks of analysis that went into #3415 alone was a whole lot more work than that would ever be. In the end it saves precious developer time now spent on policing 3rd party code.
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
Dogeocin need to resolve two issues to support the Fast & Scal payment. |
Beta Was this translation helpful? Give feedback.
-
In less than 2 months, the final year of regular LTS support for Ubuntu Focal begins, which we use for builds and releases. Although I don't mind upgrading the build system, every two years a lot of people spend a lot of time "down", because we're facing a dysfunctional CI, broken gitian scripts, have an increasing set of patches to maintain for backward compatibility, and are unable to upgrade some pinned dependencies.
I have previously mentioned that we need to have a functional new major release sooner rather than later, because of the difficulty of keeping outdated dependencies up-to-date. The target for this new major has for the last 3 years been 1.21.
However, we lack so much momentum on that effort for 2 years now, that (a) I don't think we'll be ready with a first release candidate before April, and (b) it's already a suboptimal target in terms of getting the latest Bitcoin Core base release, as a lot has been improved in their 5 subsequent releases.
Instead of developing improvements and new features into 1.14, it's also possible to base a 1.15 off 1.14.7 once it's released, and be able to get rid of some constraints, to focus on more important work:
1.14.x would remain maintained for bug- and security fixes, but not touch any functionality on it anymore. This would be comparable to an "extended support" phase, where for a limited time any bugfixes can be backported, and then could be archived as EOL.
Perhaps the biggest upside would be that this is by far the least risky means to do major updates, as this approach doesn't require throwing away years of work on stabilization and bugfixing. The downside of a construction like this would be that there will be more distractions from 1.21 than there already are.
This is just an idea I've been playing with. I'd appreciate learning everyone's thoughts on this - please do not hesitate to share your view.
Beta Was this translation helpful? Give feedback.
All reactions