❦ 31 mars 2021 10:35 +02, Willy Tarreau:
>> Thanks Willy for the quick update. That's a good example to avoid
>> pushing stable versions at the same time, so we have opportunities to
>> find those regressions.
>
> I know and we're trying to separate them but it considerably increases the
> required effort. In addition there is a nasty effect resulting from shifted
> releases, which is that it ultimately results in older releases possibly
> having more recent fixes than recent ones. And it will happen again with
> 2.2.12 which I hope to issue today. It will contain the small fix for the
> silent-drop issue (which is already in 2.3 of course) but was merged after
> 2.3.9. The reporter of the issue is on 2.2, it would not be fair to him to
> release another 2.2 without it (or we'd fall into a bureaucratic process
> that doesn't serve users anymore). So 2.2.12 will contain this fix. But
> if the person finally decides to upgrade to 2.3.9 a week or two later, she
> may face the bug again. It's not a dramatic one so that's acceptable, but
> that shows the difficulties of the process.
It's a bit annoying that fixes reach a LTS version before the non-LTS
one. The upgrade scenario is one annoyance, but if there is a
regression, you also impact far more users. You could tag releases in
git (with -preX if needed) when preparing the releases and then issue
the release with a few days apart. Users of older versions will have
less frequent releases in case regressions are spotted, but I think
that's the general expectation: if you are running older releases it's
because you don't have time to upgrade and it's good enough for you.
For example:
- 2.3, monthly release or when there is a big regression
- 2.2, 3 days after 2.3
- 2.0, 3 days after 2.2, skip one out of two releases
- 1.8, 3 days after 2.0, skip one out of four releases
So, you have a 2.3.9. At the same time, you tag 2.2.12-pre1 (to be
released in 3 working days if everything is fine) and you skip skip 2.0
and 1.8 this time because they were releases to match 2.3.8. Next time,
you'll have a 2.0.22-pre1 but no 1.8.30-pre1 yet.
If for some reason, there is an important regression in 2.3.9 you want
to address, you release a 2.3.10 and a 2.2.12-pre2, still no 2.0.22-pre1
nor 1.8.30-pre1. Hopefully, no more regressions spotted, you tag 2.2.12
on top of 2.2.12-pre2 and issue a release.
--
He hath eaten me out of house and home.
-- William Shakespeare, "Henry IV"
