Consider tagging a new release

[twrightsman]

I tried posting this to the mailing list but I was blocked due to not being a member.

Ledger's last tagged release, 3.3.2, is failing to build on more recent versions of CMake and Boost but the master branch as of https://github.com/ledger/ledger/commit/297801247b91ba668562b97d5ae7147d78be7681 seems to be working just fine.

Could you please consider tagging a new release soon?

[jwiegley]

@twrightsman Thanks for making me realize that there was a large pending queue of memberships to the mailing list. I wasn't received any notices from Google about this, and so I've approved everyone in the queue.

You're right, we should tag a new release now.

[twrightsman]

Thank you @jwiegley! That would be much appreciated. And thanks for your work maintaining ledger.

[bremner]

The version (3.3.2) in Debian is hitting these same issues with Boost and CMake. In about a month this will lead to the removal of ledger from Debian Testing. I looked briefly at packaging a snapshot, but its a bit non-trivial/confusing as master is not a descendant of the last tag. I can sort out the git issues, but I prefer not to deal with it twice. So for now I'm holding off updating the Debian package until there is a new tag.

[jwiegley]

I think this week could be good for cutting a new release tag. @afh any thoughts?

[afh]

I see much value in ledger remaining in Debian, especially since a ledger release is long overdue.

I think there is value in doing a bit of release planning and creating an issue for the next 2–3 release to coordinate the work.

I'm okay with moving fast(er) with the next release to have it out and follow up with more coordinated releases, @jwiegley.

[jwiegley]

Thank you @afh, I'd be happy to commit some time here as well. I believe the next version should be 3.4, maybe let's get together our list of issues until we can get there? Which would you suggest?

[afh]

That's marvellous to hear, @jwiegley 👏

I took the liberty to rename the previous 3.4 milestone to 3.5.0 without any due date and the previous 3.3.x milestone to 3.4.0 with a due date of September 23rd. Feel free to rename or change as you see fit. I just wanted to get started on a more coordinated effort for releases.

If you are okay with using milestones for roadmap/release plannning, @jwiegley, let's add existing and new issues to the milestones, and even create new milestones if we feel an issue should be addressed even further into the future.

In the meantime I'll go over the issues in 3.4.0 to see whether they are still reproducible or not and maybe even create PRs to address them (see #2461 🙂).

Would the GitHub discussions or the Wiki be a suitable place to have a conversation about larger goals and ideas for the project?

[jwiegley]

Sounds good, although I have a trip coming up until the 29th, and will be very busy leading up to that trip, so my own help toward this release will need to wait for October.

[jwiegley]

I think GitHub discussions is a better place than the Wiki.

[afh]

Thanks for the heads up regarding your trip, John, that's helpful to know. I'll familiarize myself with GitHub discussions to propose a structure and some ideas regarding ledger's future development and direction.

@bremner is there a more specific date in regards to ledger being planned for removal in Debian testing? I think that could help guide our efforts of when we should publish a new release in order to avoid removal as well as what we might want to include in the immediate and following releases.

[twrightsman]

I'm not @bremner but I'm also involved with Debian, looks like the CMake 4 transition was delayed to the start of October. Once that transition happens and the bug severity is re-upgraded, then 2-4 weeks after that is when ledger gets removed if nothing else happens, so mid-October?

[afh]

Thanks for chiming in, @twrightsman, very much appreciated! I've bumped the 3.4.0 milestone's due date to October 7th and made CMake 4 compatibility a personal priority.

[afh]

Happy to report that I was able to build the current state of the master branch with CMake 4.1.1.

So I believe it's less about making ledger's build process CMake 4.x compatible and more about deciding which open issues should be addressed for the 3.4.0 release.

[bremner]

Travis Wrightsman @.***> writes:

twrightsman left a comment (ledger/ledger#2426)

I'm not @bremner but I'm also involved with Debian, looks like the CMake 4 transition was delayed to the start of October. Once that transition happens and the bug severity is re-upgraded, then 2-4 weeks after that is when ledger gets removed if nothing else happens, so mid-October?

That removal is scheduled for 1 week from today.

[jwiegley]

@afh I'd suggest we current the current master as a release, and then fix the other issues we wanted to address in a quick point release after.

[jwiegley]

@bremner I have tagged current master as 3.4.0 and will release this for your use. @afh We can address the remaining open issues that we wanted to fix in 3.4.1.

[jwiegley]

@bremner See https://github.com/ledger/ledger/releases/tag/v3.4.0

[bremner]

John Wiegley @.***> writes:

jwiegley left a comment (ledger/ledger#2426)

@bremner I have tagged current master as 3.4.0 and will release this for your use. @afh We can address the remaining open issues that we wanted to fix in 3.4.1.

Thanks John.

I've uploaded the new version to Debian unstable.

d

[jwiegley]

@bremner There was a version numbering problem in 3.4.0. I've released https://github.com/ledger/ledger/releases/tag/v3.4.1 to resolve it.

[afh]

@jwiegley I went ahead and moved all open issues from the 3.4.0 milestone to a newly created 3.4.2 milestone, so we can address these issues.

[afh]

And thank you so much, @jwiegley, for tagging a new release that was so long overdue! 🙌

[jwiegley]

@afh Yeah, I didn't realize how long it had been!!