Tomas Vondra <tomas.vondra@2ndquadrant.com> writes:
> I've pushed the REL_12_STABLE backpatches too, now. I've ended up using
> 201907031 and 201907032 - those values precede the first catversion bump
> in master (201907041), so the back branch looks "older". And there's a
> bit of slack for additional bumps (if the unlikely case we need them).
FWIW, I don't think there's a need for every catversion on the back branch
to look older than any catversion on HEAD. The requirement so far as the
core code is concerned is only for non-equality. Now, extension code does
often do something like "if catversion >= xxx", but in practice they're
only concerned about numbers used by released versions. HEAD's catversion
will be strictly greater than v12's soon enough, even if you had made it
not so today. So I think sticking to today's-date-with-some-N is better
than artificially assigning other dates.
What's done is done, and there's no need to change it, but now you
know what to do next time.
> We might have "fixed" this by backpatching the commit with the extra
> catversion bump (7b925e12) but the commit seems a bit too large for
> that. It's fairly isolated though. But it seems like a bad practice.
Yeah, that approach flies in the face of the notion of feature freeze.
regards, tom lane