mirror of
https://github.com/hickory-dns/hickory-dns.git
synced 2026-04-25 03:05:51 +03:00
[GH-ISSUE #2206] 0.25 Release #919
Labels
No labels
blocked
breaking-change
bug
bug:critical
bug:tests
cleanup
compliance
compliance
compliance
crate:all
crate:client
crate:native-tls
crate:proto
crate:recursor
crate:resolver
crate:resolver
crate:rustls
crate:server
crate:util
dependencies
docs
duplicate
easy
easy
enhance
enhance
enhance
feature:dns-over-https
feature:dns-over-quic
feature:dns-over-tls
feature:dnsssec
feature:global_lb
feature:mdns
feature:tsig
features:edns
has workaround
ops
perf
platform:WASM
platform:android
platform:fuchsia
platform:linux
platform:macos
platform:windows
pull-request
question
test
tools
tools
trust
unclear
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/hickory-dns#919
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @bluejekyll on GitHub (May 4, 2024).
Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/2206
I want to start tracking what we need for the next release. I'm thinking it might be a good idea to start releasing some alphas, as I think we're waiting on a few upstream things. Thoughts?
ringquinn... others
@djc commented on GitHub (May 4, 2024):
I noticed that we now also depend on h3, so I started a PR for upgrading h3-quinn to Quinn 0.11 already.
@djc commented on GitHub (May 21, 2024):
Draft PR for the TLS upates in #2217.
@AaronKutch commented on GitHub (May 22, 2024):
the
smallvecversion and some other utility crates are quite old, could they be updated if it doesn't conflict with MSRV?@djc commented on GitHub (May 22, 2024):
@AaronKutch they should! If you want to help out with that, it would be greatly appreciated!
@AaronKutch commented on GitHub (May 22, 2024):
Could I update several crates to only specify the minor version instead of patch version, when their repos indicate stricter MSRV guarantees (the last time a lot of them had their MSRV updated, it was to 1.56 because of syn 2)? E.x. most of the things that aren't async runtimes and ssl related stuff.
@djc commented on GitHub (May 22, 2024):
I'm not sure what you mean? We don't want to pin dependencies for MSRV reasons -- we just keep the versions in
Cargo.locklow enough that CI can still pass.@AaronKutch commented on GitHub (May 22, 2024):
In the workspace .toml, there are dependencies that specify down to the patch version, is that what pinning versions too specifically would mean? In most crates, the MSRV is only updated across minor version changes at most, with a few exceptions like the
backtracecrate.@djc commented on GitHub (May 22, 2024):
I think you're misunderstanding how Cargo manifest dependency specifications work. In Cargo, dependencies without an explicit operator work like they have an implicit
^operator, so any semver-compatible newer version can be used. Since there's not currently a smallvec 2.x version, our dependency specification is already compatible with the newest version of smallvec (and if you look atCargo.lockyou can see that we currently use 1.13.2 for testing).So as far as I can tell from a quick glance, the only dependency where we're actually lagging is prefix-trie, which has recently had a 0.4.0 (and 0.4.1) release which we should pick up.
@AaronKutch commented on GitHub (May 22, 2024):
I think I have been misunderstanding how cargo updates versions this whole time. I always thought the way it worked was that if there were an array of x.y.z versions and "x" was specified, then cargo was allowed to update the y and z. If "x.y" was specified, then it could only update the z. Finally, if "x.y.z" were specified then it would fix it to that exact version. I did not realize it could jump to just any SemVer compatible version, I thought that was what the modifiers like
>=did. It seems like~does what I expected, I don't know how I never noticed this. The only crates that can actually be updated right now by changing the .toml ish3*,prefix-trie,quinn, andrustls.@djc commented on GitHub (May 23, 2024):
Most of those are taken care of in #2217, though.
@NobodyXu commented on GitHub (Jul 28, 2024):
Now that quinn, rustls and ring is upgraded, can we have a new release please?
I'm looking forward to get rid of ring 0.16 workaround for aarch64-pc-windows-msvc from cargo-binstall
Than you for all the work on hickory-dns!
@bluejekyll commented on GitHub (Jul 28, 2024):
@djc, I’m happy to punish another alpha. Anything you think we need before then?
@djc commented on GitHub (Jul 28, 2024):
@bluejekyll why not just publish 0.25.0? It's been a long time.
(Or if not, maybe update the OP with a list of stuff that you'd like to see merged before release.)
@bluejekyll commented on GitHub (Jul 29, 2024):
I can do that, though, I thought we had discussed waiting for some of the recursor work to land, we’re still waiting on the nsec3 validation for example.
@djc commented on GitHub (Jul 31, 2024):
There's always more to do -- I think it'd be okay if we do another semver-incompatible release in a few months (say, after the audit is complete), which would presumably not have all that large changes anyway. For now, IMO it's worthwhile to release all the changes we've accumulated over the past 10 months and allow people to get rid of all the duplicate dependencies from the rustls stack etc, and expose the current set of changes (including the
RDataoverhaul, I think?) to a wider audience.@NobodyXu commented on GitHub (Aug 6, 2024):
Seconded, cc @bluejekyll we'd really want a new release of hickory-dns, to use ring 0.17 which added support for aarch64-pc-windows-msvc
@bluejekyll commented on GitHub (Aug 6, 2024):
I'm happy to publish 0.25, but I do want to see if we can get any feedback on the new UDP -> TCP logic in the resolver. If that bakes for a week or so with no issues, then we can do 0.25, sound good?
I just published 0.25.alpha.2 today.
@NobodyXu commented on GitHub (Aug 7, 2024):
Thank you!
Release 0.25 in one week, if no one complains about 0.25.alpha.2 sounds good!
I could update cargo-binstall and cut a release as well, so that people could test it!
@NobodyXu commented on GitHub (Aug 10, 2024):
FYI I just published cargo-binstall v1.10.0 using 0.25.0-alpha.2, if there's any bug report related to hickory-dns, I'd forward them here
@ibigbug commented on GitHub (Aug 30, 2024):
Hey guys, it's been a while, any updates?
@NobodyXu commented on GitHub (Aug 30, 2024):
@bluejekyll cargo-binstall has been using 0.25.0-alpha and we didn't receive any issue/bug reporting regarding dns
@djc commented on GitHub (Sep 25, 2024):
Looking at open PRs, things that we might want to merge before release:
DNSSEC stuff:
Should finish this up, external contributor:
Not release blocking but good to merge:
@NobodyXu commented on GitHub (Sep 25, 2024):
Would it make sense to use a more frequent/rolling release schedule?
I.e. it has been so long between release and that also make adoption of new features/bugfix longer than expected.
IMHO anything that does not change existing API probably shall not block a new 0.25.0, new features can always be added in a patch release.
@djc commented on GitHub (Sep 25, 2024):
@NobodyXu what is the driver for you? Can you work with alpha/beta releases?
The reality is that no one is really funding maintenance of hickory-dns so although I've recently been spending a bunch of time during unemployment (and have been unable to find any organizations that wanted to fund my work maintaining Hickory DNS) there is always pretty limited capacity among maintainers. I think time from @bluejekyll who's effectively the lead maintainer has been especially scarce.
From the above PRs, most of these do actually change public API, only a few ones don't. From that perspective, I agree that #2437 and #2388 probably don't need to block the release, although they (along with #2428) stand in for a broader concept of robust DNSSEC.
Maybe it would be good to also have some governance discussion?
@NobodyXu commented on GitHub (Sep 25, 2024):
Mainly for cargo-binstall, drop-in replacement for cargo-install which installs pre-built binaries.
Yes, we are already using latest alpha version of hickory-dns.
Sorry mate, unemployment in today's economy is terrible time.
I'm willing to donate monthly to hickory-dns and send the link around social media as well.
Thanks, yeah then that makes sense to postpone the 0.25 release a bit, though I do hope we can get some alpha releases.
I think we definitely would want the leadership council of rust-lang to provide some funding, or at least some help from them, like a blog post for hickory-dns to call for help and donation.
@djc commented on GitHub (Sep 25, 2024):
My unemployment isn't really a big deal and I don't think personal donations are necessarily the best solution, but I do think organizations relying on hickory-dns in some way should help sustain the continued maintenance.
I think it would make sense to proactively drop another set of alpha releases, but would be good to hear what @bluejekyll thinks.
Sorry -- by governance I meant more how we run the project in terms of whether we have some kind of release schedule, what maintainers are responsible for what. I'm not sure Hickory DNS rises to a level where the Foundation or Project would need/want to have a call to funding -- I imagine many projects would want that kind of attention.
@NobodyXu commented on GitHub (Sep 25, 2024):
True, I believe it shall have more small, incremental patch releases.
I do think hickory-dns worths the attention of foundation, it's something does worth raising.
@bluejekyll commented on GitHub (Sep 26, 2024):
@NobodyXu, I hear you. It's good seeing so much interest in the project, but also to leave us a little breathing room and time to discover issues before "major" releases (until we hit 1.0), my goal is to make sure that disruptive changes have time to bake. That's why we're doing alpha releases.
I'm always happy to push new alpha releases off the current mainline, but I'm uncomfortable publishing major releases as that will increase the burden on our limited contribution time.
Is the discovery of the alpha releases the primary issue that you're worried about?
@NobodyXu commented on GitHub (Sep 26, 2024):
Yeah that'd be good enough for me.
hmm no, I was worried that the hickory-dns project does not receive enough help/attention.
@djc commented on GitHub (Sep 27, 2024):
@bluejekyll can you take care of doing another alpha release? I'm not sure how you did the changelog for the last one.
@johnhtodd commented on GitHub (Nov 8, 2024):
Hi - fairly new to paying attention to the project, so apologies if my once-over on the notes above is a bit naïve.
On the topic of funding (which is sadly near to my focus for $dayjob): NLNet Labs might fund a bit of this work (despite possibly a conflict of interest) because it's great to have a variety of standards-based DNS tools. Also, you may want to talk to the German Sovereign Fund, as this might be up their alley. Also perhaps Comcast, who does sponsorships for this kind of work. All these funders are very interested in encryption and security of the DNS, especially where they can be used as "libraries" for inclusion into other packages. Do you participate at all in DNS-OARC? You may consider it, if not.
My interest in the release is also funding-related, indirectly. We (Quad9) are using Hickory-DNS embedded in Vector (https://vector.dev/) as Vector is our primary dnstap ingestion/aggregation platform. We have some funding opportunities related to DNSSEC reporting, and those in turn hinge on correct and complete EDE reporting. There was a recent PR (https://github.com/hickory-dns/hickory-dns/pull/2151) we sponsored that permits multiple EDNS messages, but I suspect the Vector team will only integrate after a formal release and not from an alpha.
Are there any guesses as to when a "release" candidate will next be ready? The lack of a release gates a lot of complexity on our side for compiling custom versions of Vector.
Lastly: we (directly) might be able to put some funding together or fund some patches for development of test functionality for EDSR (https://datatracker.ietf.org/doc/draft-jt-add-dns-server-redirection/) or for authoritative DOT (server or client - https://engineering.fb.com/2018/12/21/security/dns-over-tls/ or https://blog.powerdns.com/2022/06/13/probing-dot-support-of-authoritative-servers-just-try-it) - should I start another thread on that somewhere as an issue?
@djc commented on GitHub (Nov 8, 2024):
@johnhtodd thanks for joining this conversation!
So I left my job a few months ago and have since been trying to find funding for my open source work, and have been doing a bunch of Hickory DNS work in parallel. I did apply for a fellowship from the Sovereign Tech Fund. Do you have any contacts at Comcast? I am not sure what DNS-OARC is, do you have more context on that?
I think we're going to try and get another alpha out today.
I would be interested in that, perhaps DM me on Discord or just email me so we can set up video call? (We do have some support for DoT already and I did at least previously build a Hickory-based authoritative server for Instant Domains, although it looks like we only enabled UDP and TCP in that server.)
@djc commented on GitHub (Nov 8, 2024):
Preparing 0.25.0-alpha.3 here:
@djc commented on GitHub (Nov 8, 2024):
The 0.25.0-alpha.3 release has been published. This is really the latest and greatest version of the project, and the alpha tag merely means that we're finishing up some remaining issues and making a few more semver-incompatible changes.
@zonyitoo commented on GitHub (Dec 1, 2024):
@djc When will v0.25 release? Could we expect that it will be released in early December?
@djc commented on GitHub (Dec 2, 2024):
I have high hopes that it could be released in the first half of December, but since there is no funding for this work: no guarantees.
@djc commented on GitHub (Dec 9, 2024):
Okay, here's what I'd like to merge before releasing. I guess this is pretty ambitious: I have a bunch of time to get stuff done, but I depend on others for reviews so not sure if releasing in December is feasible with this plan.
@zonyitoo commented on GitHub (Dec 31, 2024):
Happy New Year 2025. @djc
@NobodyXu commented on GitHub (Feb 8, 2025):
Feature dns-over-native-tls seems to be removed from hickory-resolver but the document isn't updated, is that intended @djc ?
It's also not included in release changelog
@djc commented on GitHub (Feb 8, 2025):
@NobodyXu not intended, would be great if you can submit a PR!
@NobodyXu commented on GitHub (Feb 9, 2025):
cc @djc Based on the commits it seems that removing of it is actually intended, but the documentation didn't get updated?
github.com/hickory-dns/hickory-dns@ca22ea794cgithub.com/hickory-dns/hickory-dns@df8eab62b7To be fair, I prefer rustls over native-tls and I'm ok with sunsetting openSSL, I just want to double check if it's actually removed as it breaks my CI but the feature doc in docs.rs says it's still supported, so a bit confusing for me.
I could open a PR to update the documentation to remove doc for feature dns-over-native-tls
@djc commented on GitHub (Feb 9, 2025):
Yes, that's what I meant -- the removal was intended, the lack of documentation changes is an oversight.
@NobodyXu commented on GitHub (Feb 9, 2025):
Thanks for clarification, opened #2758
@jcgruenhage commented on GitHub (Feb 18, 2025):
0.25.0 has been pushed into the future for quite a long time by now. What's actually still missing before we can have a final release candidate and then a proper release if that RC doesn't surface any major problems?
@djc commented on GitHub (Feb 18, 2025):
@djc commented on GitHub (Feb 26, 2025):
I think we're pretty much ready to go with these final changes:
@jcgruenhage commented on GitHub (Feb 28, 2025):
Thanks @djc for pushing this through! :)
I see all the PRs/issues linked here merged, the version bump and changelog merged on main, but the releases aren't uploaded to crates.io yet and there is no tag yet either.
Anything we can still help with? Happy to test
c141df9468in my projects for example.@djc commented on GitHub (Feb 28, 2025):
I'm basically done, @bluejekyll mentioned he wanted to have a look before release. Rest assured that I will mention here when the release has been published.
@djc commented on GitHub (Mar 10, 2025):
FWIW, we're now holding the release for a fix for the #2428 regression.
@djc commented on GitHub (Mar 18, 2025):
It is done. Sorry that it took so long -- go forth and upgrade!