DOC: start 1.0.4

[simonjayhawkins]

NOTE: opened against 1.0.x branch as to not commit to release at this stage.

I think could backport a few PRs moving the whatsnews and only after a release remove from 1.1 whatsnew on master. This gives us the chance to easily abandon the release at any time.

[jreback]

lgtm. feel free to merge things as needed to this branch.

[jorisvandenbossche]

This needed to be merged in master first / as well (or did that already happen in another PR?)

[simonjayhawkins]

This needed to be merged in master first / as well (or did that already happen in another PR?)

purposefully done it this way, see OP

NOTE: opened against 1.0.x branch as to not commit to release at this stage.

was planning to copy release notes on backports verbatim, then when ready to do a release, tidy up the whats new to be more applicable and then following a release, remove the applicable release notes from 1.1 whatsnew.

but could also work against master. wdyt?

[jorisvandenbossche]

was planning to copy release notes on backports verbatim, then when ready to do a release, tidy up the whats new to be more applicable and then following a release, remove the applicable release notes from 1.1 whatsnew.

Yes, I think that is fine, but for backporting the PRs verbatim, you don't need this file (yet) in the 1.0.x branch, right?

But also in that workflow, the PR that fixes up the whatsnew files (moving the appropriate whatsnew entries from 1.1.0 to 1.0.4) can be done against master + backported?

[simonjayhawkins]

Yes, I think that is fine, but for backporting the PRs verbatim, you don't need this file (yet) in the 1.0.x branch, right?

i meant copy the release note from 1.1 whatsnew to 1.0.4 whatsnew without changes in the backport PRs

so the 1.0.x branch doesn't have a 1.1. whatsnew and master doesn't have a 1.0.4 whatsnew (yet)

[jorisvandenbossche]

Ah, yes, I forgot that the 1.0.x branch has no 1.1 file, so you can't just backport without changing the whatsnew. Yeah, then that workflow seems fine to me to move the whatsnew inside the backport PR

[simonjayhawkins]

Yeah, then that workflow seems fine to me to move the whatsnew inside the backport PR

it does mean that each backport needs to be done manually, since auto backports fail. so there maybe a better workflow involving having a 1.1 whatsnew in 1.0.x temporarily.

the other downside is that any PRs in the pipeline that are suitable for backport can't add the release note to 1.0.4.

[jorisvandenbossche]

Was thinking the same and wondering if adding a "blank" 1.1.0 file (or only with the headers) would help, but it's quite possible that this would still give conflicts though in almost all cases in the whatsnew file.
But it could be worth to try out.

[jorisvandenbossche]

(in general, for future releases, I think it will be easier to assume the bugfix release will happen, and when it's clear that it doesn't happen, it's easy to move the whatsnew entries from eg 1.0.4 to 1.1.0 and delete 1.0.4 file in one PR, instead of the other way around)