Referenced oldest but still maintained version in contributing documenta...

[dosten]

...tion.

Q	A
Doc fix?	yes
New docs?	no
Applies to	2.2+
Fixed tickets	-

[wouterj]

I'm going to close this one. The 2.2 branch wasn't deprecated when 2,2 was released (you can imagine why... ;-) ). And changing it in that branch is against our update process:

When a Release reaches "end of maintenance"

...

• All branches still under maintenance (e.g. 2.2 and higher) are updated to reflect that pull requests should start from the now-oldest maintained version (e.g. 2.2).

[xabbuh]

From the document you are refering to:

When a release reaches its end of maintenance, the following items are done. For this example, suppose version 2.1 has just reached its end of maintenance:

• [...]
• All branches still under maintenance (e.g. 2.2 and higher) are updated to reflect that pull requests should start from the now-oldest maintained version (e.g. 2.2).

[...]

For me, that's exactly the case with this PR.

[wouterj]

No, when 2.2 reached end of maintenance, branch 2.3 and higher are under maintenance, 2.2 is not.

This PR is fixing it for the 2.2 branch, the 2.3+ branches are already updated with this.

[xabbuh]

But we are talking about 2.1 which indeed reached its end of maintenance. Thus, according to the steps to be done pull requests for bugfixes should be based on the 2.2 branch. And this is currently not reflected in the documentation.

If someone is willing to contribute he or she may currently be tempted to start with the 2.1 branch:

All bug fixes merged into maintenance branches are also merged into more recent branches on a regular basis. For instance, if you submit a patch for the 2.1 branch, the patch will also be applied by the core team on the master branch.

[wouterj]

after a short chat with @xabbuh I think I was wrong. I'm a bit dizzy about all these versions currently, so I just reopen it and let @weaverryan decide on this one.

[weaverryan]

Hi guys!

Yes, it can be confusing, but I'm glad you all went back to our written documentation for our release process. That means we'll be consistent, and if there is some way to improve that process, we can change that document :).

In this case, I also agree with @xabbuh's last comment - I think this PR perfectly addresses what should have happened when 2.1 reached end of life (we didn't have our release process in place then, so we're just catching up a little still, which is totally fine).

So, I'm going to merge in - thanks Diego for this!