3.11 release plan & Maintenance discussions

[rrthomas]

[Copied from rrthomas#8]

A quick backwards-compatible release with essential bug-fixes and functionality enhancements only. To-do list:

• Fix caching problems (Cache issues in v3.10 rrthomas/ddclient#3)
• Update changelog
• Contact downstream package maintainers? (Change of maintainers, change of curl dependency to be required, ...)
• Merge back into the original repo
• Set up signed tags (and commits)
• Update docs repo with latest changes

[LenardHess]

• Update docs repo with latest changes

[LenardHess]

Also - the link to the caching problems issue wasn't copied over correctly

[rrthomas]

Thanks @LenardHess, I've added your item and fixed the link.

[Majiir]

What's left to do here? It looks like most of the TODOs relate to switching repos which is no longer necessary.

[rrthomas]

@Majiir I have ticked the box for the item related to changing repos. The other two still need doing.

[LenardHess]

@rrthomas Since we got quite a few provider updates and new implementations pending now - I'd say we do these steps

1. Get v3.11.0 out the door
2. Work on v3.11.1:
   a. Pull in provider changes
   b. Check in with downstream maintainers (including letting some time pass in case anything pops up delayed)
3. Get started with deprecation/cleanup discussions for v4.0.0 (iirc. I had thoughts about your cleanup branch but haven't bothered writing them down yet)

For 1. in particular I'd still opt to pull any currently open pull request that fixes provider regressions. I.e. the porkbun fix won't qualify as porkbun is newly added with v3.11.

[TinfoilSubmarine]

FWIW, I've got the master branch packaged and working on Void so once a release is made Void should be all set.

[rrthomas]

@rrthomas Since we got quite a few provider updates and new implementations pending now - I'd say we do these steps

1. Get v3.11.0 out the door

2. Work on v3.11.1:
   a. Pull in provider changes
   b. Check in with downstream maintainers (including letting some time pass in case anything pops up delayed)

3. Get started with deprecation/cleanup discussions for v4.0.0 (iirc. I had thoughts about your cleanup branch but haven't bothered writing them down yet)

This all sounds good to me. Thanks for working this all out!

For 1. in particular I'd still opt to pull any currently open pull request that fixes provider regressions. I.e. the porkbun fix won't qualify as porkbun is newly added with v3.11.

I agree about fixing regressions; but why not pull the porkbun fix too, since otherwise it sounds like we're shipping a broken new provider (if a fix is needed)?

[LenardHess]

My reasons for excluding the porkbun pull request from v3.11.1 are:

• The issue in question is only when a host has both IPv4 and IPv6 configured and the IPv4 update fails, the IPv6 will be erroneously skipped. If the error was transient (i.e. random connection drop) it will get remedied in the next update cycle (5 mins by default). If its a permanent issue with IPv4 update I'd expect the IPv6 update to also not work due to the same issue (i.e. provider not reachable when your internet is down).
• I want to get v3.11.1 out soon, and I want to avoid to get stuck in "Just one more thing" (which I do way too often)
• I would want v3.11.2 to follow not too long after v3.11.1 - we already have multiple provider fixes & additions piled up to warrant another release fairly soon.
• I want the maintainer switch to be as easy as possible on downstream maintainers. The less code written or signed off by - to them - new people, the easier. (I.e. if i were one of em I'd prefer a "Hey, we're the new maintainers and got this release with mostly just the leftover stuff from the former maintainers" over "Hey, we're new and wrote a bunch of new stuff already"

[rrthomas]

Your reasons are excellent, @LenardHess!

[indrajitr]

@rrthomas, @LenardHess: Thanks for bringing this project back on track! Do you have a tentative timeline to get 3.11 out?

[LenardHess]

The last weeks life got in the way a bit, I'm hoping to resume continuing ddclient stuff next week. The release itself doesn't require much, so it should be done fairly quickly once I'm back at it.

[bjornfor]

Hi 👋 NixOS 23.11 is planned for release in a few weeks and TLDR unless there is a new ddclient release by then we won't have ddclient in NixOS 😢 Is there anything I can do to to help? Is it just docs left (like the OP says)?

[LenardHess]

Hi @bjornfor
yes, it's just getting the release notes, documentation updates and setting up the signed tag.

For the signing I spent way too much time diving down the GPG rabbit hole, but for the purposes of getting this release out I'll stick to a simple SSH key for signing the tag in Github instead.

I'll see that we get this out the door in time 👍

[LenardHess]

v3.11.0_1 is finally out of the door. Apologies for the period of radio silence leading up to this.

Next steps for v3.11.0_2 (or 3.11.0 hopefully) is to get the current batch of PRs sorted out.
Before I want to make this 3.11.0 I do want a minimum amount of time (1-2 months maybe?) having passed since 3.11.0_1 - just so downstream has ample time to update and/or report issues.

[bjornfor]

@LenardHess: Thanks!

(I'm resurrecting ddclient in NixOS here: NixOS/nixpkgs#261241.)

[nemchik]

As an FYI, LSIO is only building releases (not pre-releases). Our image is still released with 3.10.0 being the latest. If pre-releases are desired we can add builds for that. Our build system would mark pre-releases as a separate tag (ex: development, or whatever makes the most sense from you) and the latest tag would remain only stable releases.

[LenardHess]

@nemchik ok - considering that I'd say we:

• Release v3.11.0 (not prerelease) within a few days (next weekend probably). This would just be v3.11.0_1 with updated version number & Changelog.
• Pull in the pending pull requests in for v3.11.1.

@rrthomas sounds good?

[fichtner]

@LenardHess yeah that sounds great. you could possibly create a branch for 3.11 and base 3.11.x off of that if it's not too much work, but upstreams would appreciate it. In FreeBSD 3.10 was never adopted, pre-releases are unlikely to be picked up so going into a real release directly is the best way forward in getting valuable release feedback for eventual 3.11.x improvements.

[rrthomas]

Sounds good, and I agree that calling it a release is more likely to get us feedback.

[LenardHess]

Release v3.11.0 is out!
Next up is the handling of all the various pull requests for v3.11.1

I am not yet sure how I want to handle prereleases in the future, any input on downstream preferences is welcome!

[rrthomas]

Many congratulations @LenardHess!

[nemchik]

From the LSIO perspective, we don't have a preference. If user facing pre-releases are valuable or in demand we can add them, otherwise we can stick to stable releases for the image. It's not a big difference for us.