[GH-ISSUE #1922] 0.23.0 release planning #815

Closed
opened 2026-03-16 00:21:37 +03:00 by kerem · 31 comments
Owner

Originally created by @djc on GitHub (Apr 26, 2023).
Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/1922

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

@bluejekyll what are we waiting for?

I'll nominate:

  • #1916 (but this is blocked on a Quinn release, hopefully coming soon now -- its release planning issue is https://github.com/quinn-rs/quinn/issues/1528)
  • #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 #1876, but that might be a bit of a chicken and egg situation
  • #1938 provider API revisions

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

Originally created by @djc on GitHub (Apr 26, 2023). Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/1922 Just getting this started to help people track what's blocking the release. @bluejekyll what are we waiting for? I'll nominate: - [x] #1916 (but this is blocked on a Quinn release, hopefully coming soon now -- its release planning issue is https://github.com/quinn-rs/quinn/issues/1528) - [x] #1920 would be nice to have but I don't think it breaks the API (then again, it's pretty small anyway) - [x] Might be good to get @jeff-hiner's feedback on #1876, but that might be a bit of a chicken and egg situation - [x] #1938 provider API revisions ---- ~~Would be good to get some feedback at least on #1919~~ moved to #2008
kerem closed this issue 2026-03-16 00:21:43 +03:00
Author
Owner

@bluejekyll commented on GitHub (Apr 26, 2023):

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

<!-- gh-comment-id:1524026286 --> @bluejekyll commented on GitHub (Apr 26, 2023): I was thinking maybe we could just release a prerelease version, and just start getting that in the wild?
Author
Owner

@djc commented on GitHub (Apr 26, 2023):

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.

<!-- gh-comment-id:1524034080 --> @djc commented on GitHub (Apr 26, 2023): 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.
Author
Owner

@glts commented on GitHub (May 8, 2023):

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.

<!-- gh-comment-id:1538460479 --> @glts commented on GitHub (May 8, 2023): 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.
Author
Owner

@djc commented on GitHub (May 8, 2023):

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).

<!-- gh-comment-id:1538483551 --> @djc commented on GitHub (May 8, 2023): 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).
Author
Owner

@glts commented on GitHub (May 8, 2023):

@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' ...

<!-- gh-comment-id:1538489613 --> @glts commented on GitHub (May 8, 2023): @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' ...
Author
Owner

@djc commented on GitHub (May 8, 2023):

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.

<!-- gh-comment-id:1538492663 --> @djc commented on GitHub (May 8, 2023): > 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.
Author
Owner

@glts commented on GitHub (May 8, 2023):

All right, let's drop it.

<!-- gh-comment-id:1538504384 --> @glts commented on GitHub (May 8, 2023): All right, let's drop it.
Author
Owner

@peterthejohnston commented on GitHub (May 12, 2023):

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.

<!-- gh-comment-id:1545946368 --> @peterthejohnston commented on GitHub (May 12, 2023): 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.
Author
Owner

@cpu commented on GitHub (May 12, 2023):

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

<!-- gh-comment-id:1545958260 --> @cpu commented on GitHub (May 12, 2023): @peterthejohnston In [a comment on another PR](https://github.com/bluejekyll/trust-dns/pull/1916#issuecomment-1544123962) @bluejekyll mentioned there was a hiccup publishing that release. I think there's a plan to publish a replacement.
Author
Owner

@bluejekyll commented on GitHub (May 12, 2023):

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.

<!-- gh-comment-id:1546029289 --> @bluejekyll commented on GitHub (May 12, 2023): 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.
Author
Owner

@djc commented on GitHub (May 12, 2023):

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

<!-- gh-comment-id:1546035172 --> @djc commented on GitHub (May 12, 2023): Maybe the addition of the fuzz crate (which probably shouldn't be published)?
Author
Owner

@bluejekyll commented on GitHub (May 12, 2023):

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)

<!-- gh-comment-id:1546039573 --> @bluejekyll commented on GitHub (May 12, 2023): 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)
Author
Owner

@bluejekyll commented on GitHub (May 12, 2023):

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

<!-- gh-comment-id:1546180958 --> @bluejekyll commented on GitHub (May 12, 2023): ok, alpha.2 should now be published. I couldn't get the cargo-make script to work properly... I still need to debug that.
Author
Owner

@djc commented on GitHub (May 12, 2023):

"should not be" -> "should now be" (I can see trust-dns-proto is up on crates.io).

<!-- gh-comment-id:1546212282 --> @djc commented on GitHub (May 12, 2023): "should not be" -> "should now be" (I can see trust-dns-proto is up on crates.io).
Author
Owner

@bluejekyll commented on GitHub (May 12, 2023):

fixed, that's a typo that makes it 100% have a different meaning.

<!-- gh-comment-id:1546214482 --> @bluejekyll commented on GitHub (May 12, 2023): fixed, that's a typo that makes it 100% have a different meaning.
Author
Owner

@mokeyish commented on GitHub (May 12, 2023):

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.

<!-- gh-comment-id:1546278003 --> @mokeyish commented on GitHub (May 12, 2023): > 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](https://github.com/casey/just) 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.
Author
Owner

@bluejekyll commented on GitHub (May 12, 2023):

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.

<!-- gh-comment-id:1546398226 --> @bluejekyll commented on GitHub (May 12, 2023): 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.
Author
Owner

@bluejekyll commented on GitHub (May 15, 2023):

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

<!-- gh-comment-id:1548399255 --> @bluejekyll commented on GitHub (May 15, 2023): 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
Author
Owner

@jeff-hiner commented on GitHub (May 15, 2023):

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

<!-- gh-comment-id:1548752468 --> @jeff-hiner commented on GitHub (May 15, 2023): @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.
Author
Owner

@XOR-op commented on GitHub (May 20, 2023):

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

<!-- gh-comment-id:1555890463 --> @XOR-op commented on GitHub (May 20, 2023): Since #1938 tries to solve the problem @jeff-hiner mentions, I suggest to add this to the list until it's accepted or rejected.
Author
Owner

@djc commented on GitHub (May 22, 2023):

Added it to the list.

<!-- gh-comment-id:1556713731 --> @djc commented on GitHub (May 22, 2023): Added it to the list.
Author
Owner

@mattias-p commented on GitHub (Aug 21, 2023):

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?

<!-- gh-comment-id:1686438661 --> @mattias-p commented on GitHub (Aug 21, 2023): 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?
Author
Owner

@djc commented on GitHub (Aug 22, 2023):

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

<!-- gh-comment-id:1687634039 --> @djc commented on GitHub (Aug 22, 2023): @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.
Author
Owner

@bluejekyll commented on GitHub (Aug 22, 2023):

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

<!-- gh-comment-id:1688375032 --> @bluejekyll commented on GitHub (Aug 22, 2023): Yeah, we can do that. I haven't seen any negative issues filed on the alpha's...
Author
Owner

@bluejekyll commented on GitHub (Aug 22, 2023):

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

<!-- gh-comment-id:1688386580 --> @bluejekyll commented on GitHub (Aug 22, 2023): @djc, want to cross out the items in your list above that are not in the 0.23 release?
Author
Owner

@bluejekyll commented on GitHub (Aug 22, 2023):

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?

<!-- gh-comment-id:1688401634 --> @bluejekyll commented on GitHub (Aug 22, 2023): 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?
Author
Owner

@XOR-op commented on GitHub (Aug 22, 2023):

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.

<!-- gh-comment-id:1688439160 --> @XOR-op commented on GitHub (Aug 22, 2023): 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.
Author
Owner

@bluejekyll commented on GitHub (Aug 22, 2023):

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

<!-- gh-comment-id:1688444961 --> @bluejekyll commented on GitHub (Aug 22, 2023): I'll start preparing the 0.23 release now. If anyone has objections, please raise them here.
Author
Owner

@bluejekyll commented on GitHub (Aug 22, 2023):

#2007 will be the 0.23.0 release.

<!-- gh-comment-id:1688475967 --> @bluejekyll commented on GitHub (Aug 22, 2023): #2007 will be the 0.23.0 release.
Author
Owner

@bluejekyll commented on GitHub (Aug 22, 2023):

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.

<!-- gh-comment-id:1688551553 --> @bluejekyll commented on GitHub (Aug 22, 2023): 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.
Author
Owner

@bluejekyll commented on GitHub (Aug 22, 2023):

see #2008 for any carried over work

<!-- gh-comment-id:1688600143 --> @bluejekyll commented on GitHub (Aug 22, 2023): see #2008 for any carried over work
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/hickory-dns#815
No description provided.