New BIND releases are available: 9.18.28, 9.20.0

[Victoria Risk]

Adam,

> What is the proper mapping of "Current Stable, ESV", "Development", and "New Stable" BIND versions to their respective COPR repos? I feel like it should be obvious, but I am missing something.

I did consider whether we should summarize this in the announcement. Perhaps I should have. It is confusing but as Ondřej pointed out, it was discussed here, and was intentional for user benefit. We think that most users are unlikely to want to swap their production environment from one stable version to a new .0 stable version the day it is released, so this design was supposed to minimize surprise major version upgrades.

BIND 9.20.0 is in the bind-dev repositories, because it is the least delta vs the last development release on 9.19. There is no new 9.19 version released today, so that == 9.20.0. So, IF you are using 9.19.x in a production environment, you should update to 9.20 to fix any CVEs that may apply in your situation.  

now (July 2024)
bind = 9.18
bind-esv = 9.18
bind-dev = 9.20.0

later (once we have a new 9.21 version, August?? 2024)
bind = 9.20.x
bind-esv = 9.18.x
bind-dev = 9.21.x

I hope this is a bit clearer. Sorry for not including this in the announcement.

Vicky

> On Jul 23, 2024, at 10:31 AM, Ondřej Surý <ondrej at isc.org> wrote:
> 
> Hi Adam,
> 
> this was discussed a month ago:
> 
> https://lists.isc.org/pipermail/bind-users/2024-June/108638.html
> 
> and we were basically asked to make the bumps in the repositories to not follow the releases.
> 
> Ondrej
> --
> Ondřej Surý (He/Him)
> ondrej at isc.org
> 
> My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours.
> 
>> On 23. 7. 2024, at 10:17, Adam Augustine <augustineas at gmail.com> wrote:
>> 
>> First, thank you all for the hard work you do on BIND.
>> 
>> What is the proper mapping of "Current Stable, ESV", "Development", and "New Stable" BIND versions to their respective COPR repos? I feel like it should be obvious, but I am missing something.
>> 
>> I think I expected 9.18.28 to appear in isc/bind-esv with this release (which it does) and for 9.20.0 to appear in isc/bind (which it doesn't, as far as I can tell anyway). 9.18.28 does appear in isc/bind as well as in isc/bind-esv, which seems reasonable (though the "07776636-isc-bind-bind" directory is hidden in isc/bind, it is accessible and referenced in the respective repo xml files). I recognize that a direct upgrade from 9.18 to 9.20 for those on the isc/bind repo might be a bit surprising at this point, despite the very clear messaging about how the versioning is meant to work, but at the same time, I wouldn't expect we want people using the isc/bind-dev repo to get 9.20.0 for production use either.
>> 
>> I don't recall how this transition was handled for 9.16->9.18, but if I recall it seemed like it just magically worked for us. But back then we weren't as aggressive about updating as we are now. I probably just missed some explanation somewhere about how the transition is meant to be handled, but my searches aren't returning anything specific to this situation. Speaking of which, is there an equivalent to the https://kb.isc.org/docs/changes-to-be-aware-of-when-moving-from-bind-916-to-918 article for 9.18->9.20? 
>> 
>> We have already upgraded most of our systems to 9.18.28, but want to move to 9.20.0 soon, but aren't certain the right way forward.
>> 
>> Thanks again for this release. I know refactoring code is extremely challenging and doesn't get the praise it deserves.
>>