Next release target: new major?

[patricklodder]

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.

[slightlyskepticalpotat]

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: ***@***.***>

[patricklodder]

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.

[Cristycanal386]

Or go all the way up and what makes you the most happy

[slightlyskepticalpotat]

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: ***@***.***>

[chromatic]

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.

[patricklodder]

I agree with that assessment; it just means we have to do some of the bigger things within a 1-year timeline, but which exact minor release these would go into can be flexible.

[daank-c]

Couple questions about this.

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.

I like this, but would it spread maintainers too thin?

• Upgrade Qt to an actively maintained version

Is this a big job? What does it entail?

[patricklodder]

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.

[georgeartem]

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: ***@***.***>

[buxiashan]

Dogeocin need to resolve two issues to support the Fast & Scal payment.
1、solve the Inscription attack issue. #like DRC/BRC20 inserted massive useless data into dogecoin ledger；
2、solve the transaction excution need too long time issue. #Fast payment when you consume at offline/online store. maybe the transaction must be finished in 3 seconds.

[patricklodder]

Neither can possibly happen on a minor release, so that's a clear message, thanks. We'll open 1.15.0 for development somewhere next week, after which it will be easier to make a pull request that does a huge refactor. I'll be looking forward to the proposals.