The fact the the release branch was merged does not impede to continue to add commits to it. In any case, I would expect fixes to LTS releases to bump the version number, so whenever a new minor version for that LTS version is to be released and it is considered final (i.e. 9.2 if 9.x is LTS), it would be merged and tagged.
Or am I missing something? On Mon, Jun 15, 2020, at 16:49, Nathan Hartman wrote: > On Mon, Jun 15, 2020 at 3:41 PM Matias N. <mat...@imap.cc> wrote: > > > Functionally, yes. But git has troubles recognizing that the cherry-picked > > commits are the same on master and generates conflicts. The merge would > > solve this in theory, since the release branch tip would end up matching a > > commit on master. > > > Suppose in the future we wish to have LTS releases -- Long Term Support, > where "Support" just means that the release line receives bugfix and > security fix maintenance for a longer period of time than regular releases. > We briefly touched on this idea recently but are not ready to do it yet. > Nevertheless, as an example only for illustration, suppose that an LTS > release is to be maintained for 2 years. > > Then, how does the strategy of merging release branches back to master > support that type of requirement? > > Nathan >
