Put the 4.6 changelogs together

[asottile]

No description provided.

[nicoddemus]

Thanks!

I lean towards show more or less by release date, similar to how Python shows their releases:

With the exception being the highest version (5.2.1 currently) is always shown first in pytest, regardless of its release date, but I'm not 100% committed to it too, so I'm +0 on this.

[blueyed]

btw: please use your fork for PRs, avoiding continuous-integration/travis-ci/push etc.

[asottile]

btw: please use your fork for PRs, avoiding continuous-integration/travis-ci/push etc.

I just used the github editor, it doesn't give you an option to write to a fork if you're a collaborator

if it's a problem, we should just change the branches filter so it doesn't run against pushes -- for example: https://github.com/pre-commit/pre-commit/blob/4bd6529c0521955265bacdbb4d6ef7c2ceec8eba/azure-pipelines.yml#L1-L5

[nicoddemus]

What I usually do is to edit my fork explicitly (IOW go to https://github.com/nicoddemus/pytest and edit from there). The problem with this approach is that my master isn't always up-to-date.

TBH @asottile always uses his fork for opening PRs, I'm sure this was something he just wanted to get done quickly and didn't have easy access to his command-line. I prefer people to (on occasion) contribute like this rather than "well I will have to get to this later" and end up forgetting and never getting that PR in.

In summary, my humble opinion is: if a contributor usually uses a fork, and for a quick fix had to use a branch in the repository on occasion, that's perfectly fine. I myself noticed it was a branch opened in the main repository, but given that it was @asottile, I just assumed he had his reasons and didn't even thought twice about it. 🤷‍♂

[blueyed]

I see. It's not a big problem, of course. The trick of doing it from your fork is good, something I wasn't aware of myself (I assume you can use a branch from a PR then if master is not up to date).

@asottile
You could also have mentioned your idea on #5952 - where IMHO this was not finished discussing, and then it would also have not been lost/forgotten.

I'm with @nicoddemus here that it is better to have them by date, if at all - I still think they do not belong in the 5.x/master branch though. But let's not bikeshed this - I accept by now that this repo is not about best practices.. :) 🤷‍♂️

[blueyed]

btw: 👍 for having better branch filters in general, since this also affects e.g. reverting via GitHub's UI.

[blueyed]

btw: for having better branch filters in general, since this also affects e.g. reverting via GitHub's UI.

=> #6032