Julian expresses objection to this plan, as discussed int he DR, it will create extra work. The proposal is to keep version 12 and to make the Q release compatible to that the upgrade can happen latter on.
This proposal is that the Q release is compatible with versions 12-16, and that DevOps can change versions at anytime prior to the November 2024 loss of support for version 12
@Craig McNally points out that this plan seem to be dependent on there being no code changes necessary for this upgrade path
@Marc Johnson asked for clarifications, @Julian Ladisch clarifies that officially we would support 12 and 16, and that the intermediate version should be implicitly supported.
@Ingolf Kuss asks if there are no code changes for version 13 why don't we go to 13 right away
@Julian Ladisch points out that there will be test code changes will be needed and that this will require two upgrades, 12-13 and then 13-16
@Tod Olson asks for clarification, the proposal will officially support 12 in the Q release, and that 16 will be tested but not officially supported, and then we will move the version as far forward as we can for the R release
@Florian Gleixner says that the jump from 12 to 16 is good for sysops because it is fewer database upgrades. He also feels that we need one release that supports multiple versions, and sees benefits to the developers
@Marc Johnson mentions that supporting 4 versions seems like a stretch
@Julian Ladisch for migration of tenants you need to support multiple versions
@Marc Johnson Feels that this DR seems to have a very wide scope
@Craig McNally we should make a decision about the Q release and we may need a formal vote. Do we move to 13 in the Q release or leave it 12
The nays carried the vote, which was interpreted as implicitly an approval of the DR
@Marc Johnson did not feel that this vote was an implicit approval of the DR
@Craig McNally did folks feel that they were voting on the implicit acceptance of the DR
@Jeremy Huff did feel that he was voting on the implicit acceptance of the DR
@Marc Johnson Dislikes the idea of voting "no" on one thing is the same as voting "yes" on another
The DR was approved and the Q release will support 12 and 16, though it should be noted that to do this, not all features from 16 will be supported
@Craig McNally this option will leave it up to the system operators to decide when to upgrade
@Tod Olson felt that the vote was to leave the officially supported version for the Q release at 12 and that there would be a separate vote for the R relase
@Craig McNally Since two people have raised this concern let's have a separate vote for the R release
The current vote indicates that the Q release will officially support version 12 of Postgres
@Marc Johnson if people want to run on a latter version of Postgres then what we officially support they can do that
@Tod Olson part of the goal is to minimize the work of the project's operations team, he would like to see an option in place that would allow for bugs in version 13 to be addressed
@Julian Ladisch points out that if there was a bug in 13 it would likely be in 16 as well, and would be addressed because of that
@Marc Johnson points out that we have not decided to support 16
@Craig McNally Vote number 2 is what version we want to run in release R? Maybe we should wait until next week to make this decision
@Marc Johnson we are not going to sign off on the approved technology list in the remaining time of the meeting, and he points out that we will support an unsupported version of Postgres for the entirety of the Q release cycle
@Florian Gleixner Postgres 16 support could be declared for a specific hotfix release
@Craig McNally this would be a new approach
Time on the meeting, and this will need to be discussed next time (Monday)