0.23.0 release planning

[djc]

Just getting this started to help people track what's blocking the release.

@bluejekyll what are we waiting for?

I'll nominate:

• Update rustls, tokio-rustls, quinn #1916 (but this is blocked on a Quinn release, hopefully coming soon now -- its release planning issue is 0.10 release planning quinn-rs/quinn#1528)
• Add the possibility to shuffle NameServers #1920 would be nice to have but I don't think it breaks the API (then again, it's pretty small anyway)
• Might be good to get @jeff-hiner's feedback on API-breaking change: Deprecate ConnectionProvider with new RuntimeProvider #1876, but that might be a bit of a chicken and egg situation
• Provider API Redesign #1938 provider API revisions

---

Would be good to get some feedback at least on #1919 moved to #2008

[bluejekyll]

I was thinking maybe we could just release a prerelease version, and just start getting that in the wild?

[djc]

Yup, getting an alpha or beta out is usually a good way to enable downstream consumers, and will help us gather more feedback for the release too.

[glts]

Please include an updated enum-as-inner dependency in 0.23.

enum-as-inner 0.5.1 is the only remaining dependency in
trust-dns-resolver whose syn dependency is still at version 1. All other
dependencies transitively include syn 2.

It would be great if for the next release of trust-dns-resolver an
updated enum-as-inner could be included, in order to eliminate any
transitive dependency on syn 1.

[djc]

enum-as-inner 0.5.1 is semver-compatible with 0.5 (which we're already using on main) so for library usage this should be covered already (the Cargo.lock file is largely irrelevant here).

[glts]

@djc Agreed. Nevertheless, 0.23 might be a good occasion to include a version of enum-as-inner that depends on syn 2, eg for those who want to try to build something with 'minimal dependency versions' ...

[djc]

Nevertheless, 0.23 might be a good occasion to include a version of enum-as-inner that depends on syn 2, eg for those who want to try to build something with 'minimal dependency versions' ...

So you're set on getting something that can satisfy minimal versions without pulling in syn 1? That seems extremely niche.

[glts]

All right, let's drop it.

[peterthejohnston]

Thanks for putting out an alpha release! I noticed that the v0.23.0-alpha.1 version doesn't seem to appear on crates.io: https://crates.io/crates/trust-dns-resolver/versions

Is that intentional? (Maybe there is a delay between the GitHub release and it ending up on crates.io?) It would be great if it could be released there so we can pull it in and do some early testing to prepare for v0.23.0.

[cpu]

@peterthejohnston In a comment on another PR @bluejekyll mentioned there was a hiccup publishing that release. I think there's a plan to publish a replacement.

[bluejekyll]

yeah, I'm working on it. Something changed in the publish command in cargo-make, it's just delayed me getting this out. I'll publish manually today. Not sure why that auto-publish broke, but something about the workspace crate ordering changed, and I'm not sure why.

[djc]

Maybe the addition of the fuzz crate (which probably shouldn't be published)?

[bluejekyll]

I think it's excluded, but from the logs on github it looks like bin tried to be published first and I don't know why that is (honestly I wrote this so long ago and it's been working fine, I can't remember how I got the crates to publish in the correct order in the first place)

[bluejekyll]

ok, alpha.2 should now be published. I couldn't get the cargo-make script to work properly... I still need to debug that.

[mokeyish]

ok, alpha.2 should now be published. I couldn't get the cargo-make script to work properly... I still need to debug that.

A question I have: Is cargo-make really needed?

If you need to define a build workflow, justfile is also a good choice, like makefile, but cross-platform.

I’m not familiar with cargo-make, it’s not as intuitive as makefile, justfule is just for reference.

[bluejekyll]

one of the nice things that cargo-make does that always makes me hesitant to switch is decent support for workspaces and building patterns related to them. I have been thinking of moving everything over to justfiles, but having deeper integration with cargo is a really nice feature of cargo-make.

[bluejekyll]

Ok, I think cargo-workspaces has all the functionality I need pretty much. I'm thinking of converting to justfiles in combination with that tool. If anyone has any other suggestions there, I'll use this issue: #1934

[jeff-hiner]

@djc Sorry it's taken me so long to get to this, but there are some structural issues with AbstractNameServer. It's easier to use than what was replaced, so I do suggest we move forward... but we need to break apart the types for DnsHandle and CreateConnection. I can't realistically create a single type that implements both.

To me the intent is CreateConnection is a factory that produces DnsHandle. The factory for a DoH provider doesn't get config information until new_connection is called. And a CreateConnection factory by itself without that information can't handle send requests.

[XOR-op]

Since #1938 tries to solve the problem @jeff-hiner mentions, I suggest to add this to the list until it's accepted or rejected.

[djc]

Added it to the list.

[mattias-p]

What's the current status of 0.23.0? It's been three months and three alphas since the last update here. Also, is there anything I could do to help out?

[djc]

@bluejekyll do you have a plan for this? What's blocking the release? I do think we should get a release out soon even if only to get rustls 0.21 which most of the ecosystem has picked up.

[bluejekyll]

Yeah, we can do that. I haven't seen any negative issues filed on the alpha's...

[bluejekyll]

@djc, want to cross out the items in your list above that are not in the 0.23 release?

[bluejekyll]

ok, it would be great if we could land #2001, #2003, #2004, and #2005 as they will have breaking changes to APIs. But they are large changes, #2001 especially. So we could push the 0.23 release and then follow closely with 0.24. Anyone have thoughts?

[XOR-op]

I think we should not push too many breaking changes at once, where users may find too many modifications they should perform after one incompatible version upgrade. IMO a closely followed 0.24 is better than a super big 0.23, since the upgrade path is smoother.

[bluejekyll]

I'll start preparing the 0.23 release now. If anyone has objections, please raise them here.

[bluejekyll]

#2007 will be the 0.23.0 release.

[bluejekyll]

Ok, once this job is done, 0.23 will be released: https://github.com/bluejekyll/trust-dns/actions/runs/5941553830

I think we should probably close this issue, and carry forward open items to 0.24.

[bluejekyll]

see #2008 for any carried over work