Skip to content

2021.09
Compare
Choose a tag to compare
@PromoFaux PromoFaux released this 11 Sep 22:31
· 617 commits to master since this release
2021.09
1a7bfdc
This commit was signed with the committer’s verified signature.
PromoFaux Adam Warner
GPG key ID: 872950F3ECF2B173
Learn about vigilant mode.

Previously, we have picked a version number of one of the internal components (most recently, FTL) and applied that to the docker container's tag. However, this sometimes causes confusion between users, but also developers (when we are not sure what to tag a docker release if FTL's version number has not changed)

Going forward, we will use a year.month[.revision] to tag docker releases with. To tag a new image, it is as simple as looking at the calendar to decide what the tag name should be. We will always try to leave any major changes until a new month rolls over. e.g if Pi-hole v6 were to be released in 2 weeks time, it would not be in the docker image until 2021.10 (that said, we can also tag pre-release versions for those that are itching to get onto the bleeding edge. This also gives us chance to make sure that none of the core Pi-hole changes break how the container operates.

There will always be a :nightly tag, which is built every night based on the dev branch of this repo, and the development/devel branches of the three components, for those who really want to live on the edge - but we don't recommend running this in production.

We have also noticed that a lot of people use Watchtower or Portainer to keep their Pi-hole containers up to date. For the same reason we don't provide an auto-update feature on a bare metal install, you should not have a system automatically update your Pi-hole container. Especially unattended. As much as we try to ensure nothing will go wrong, sometimes things do go wrong - and you need to set aside time to manually pull and update to the version of the container you wish to run. The upgrade process should be along the lines of:

  • Important: Read the release notes. Sometimes you will need to make changes other than just updating the image
  • Pull the new image
  • Stop and remove the running Pi-hole container
    • If you care about your data (logs/customizations), make sure you have it volume-mapped or it will be deleted in this step.
  • Recreate the container using the new image

Pi-hole is an integral part of your network, don't let it fall over because of an unattended update in the middle of the night.

Breaking Changes:

  • None

Docker Specific Changes:

  • 3865e77 - Introduce internal PIHOLE_TAG variable so that we can see what tag the container is...
  • 388f0f0 - Disable some more pihole functions when run from within docker, Inject a message into the debug output that lets us know it's been run in a docker container
  • 88518b0 & 56f4933 - Inject the container tag into the web interface footer
  • Set FTL REPLY addresses instead of setupVars.conf. #902
  • Improve Docker Healthcheck: Shorten dig output #905

Pi-hole Core Changes:

Pi-hole Web changes:

Pi-hole FTL changes:

  • Customizable locking while database is busy pi-hole/FTL#1156
  • Regex extension: Specify reply type pi-hole/FTL#1159
  • Update embedded dnsmasq to version 2.86
  • Improve locking during heavy TCP forking pi-hole/FTL#1134
  • Log when listening on the wildcard address pi-hole/FTL#1135
  • Improve warning messages for defect hwclocks pi-hole/FTL#1136
  • Fix crash when bind-address is used pi-hole/FTL#1132
  • Plus a lot more smaller changes that came up during our beta testing. See the Pi-hole release blog post for all the details.
Assets 2
Loading