REL: v1.4.0

[franklin-feingold]

This PR coordinates with releasing Common Derivatives into BIDS!

Following our release protocol this will be merged in 1 week pending further discussions.

[nicholst]

Hi @franklin-feingold, It's a minor issue, but I thought part of the release protocol was tidying up the PR names so that the auto-changelog is clean and professional. I mean, it's minor, but if I was scanning the change notes and a saw Enh/prov I'd have no clue what this meant; also, some are missing the FIX/ENH/etc tags.

How do we fix that now? I assume you don't just lodge a PR to change the changelog?

[effigies]

Rename the PR and it will be fixed in future changelogs.

That's an annoying one, because it wasn't merged into master, so I'd think it should be excluded...

[nicholst]

Sorry... I can rename PR's when I see it....

But, um what's the "annoying one"? Satra's Enh/prov?

[satra]

does the automation script only check closed? or merged?

[franklin-feingold]

does the automation script only check closed? or merged?

The script checks for merged PRs. We don't have additional options turned on for capturing pr's merged into master. Looking the options available I see a few different approaches.

• We could add labels to the pr's going into one of our branches. This will make it more clear when scanning the pr's which are going into master and which are merging into one of our branches. Although this strategy breaks down if we are giving slightly too granular labels (e.g. BEP vs BEP028). Each new BEP label would need to be added to our exclusion list.

• They have a release-branch flag that appears to limit to pr's to our master branch. I'll have to test it more in the coming days but this option may resolve this issue nicely.

[nicholst]

OK, well I'm not sure if I understand if the proposed solutions are forward-looking or also account for retrospective changes. FWIW, I've renamed the offending PRs:

• ENH: Add RECOMMENDED DatasetType key to dataset description [ENH] Add RECOMMENDED DatasetType key to dataset description #494
• Clarify mask/dseg/probseg in common derivatives [ENH] Clarify mask/dseg/probseg in common derivatives #489
• Reorganize derivatives [ENH] Reorganize derivatives #488
• Enh/prov [ENH] BEP028: Provenance #486

to

• [ENH] Add RECOMMENDED DatasetType key to dataset description [ENH] Add RECOMMENDED DatasetType key to dataset description #494
• [ENH] Clarify mask/dseg/probseg in common derivative [ENH] Clarify mask/dseg/probseg in common derivatives #489
• [ENH] Reorganize derivatives [ENH] Reorganize derivatives #488
• [ENH] BEP028: Provenance [ENH] BEP028: Provenance #486

Hope that's OK/correct.

[satra]

@franklin-feingold - i think i see what the reason is the provenance PR that was merged, was not merged into master. it was merged into a separate branch.

this query on PRs will reveal the set of PRs merged into master since the last release:
is:pr is:merged base:master merged:>=2020-04-14

and if you wanted to do additional tracking, you can indeed setup milestone labels.

[franklin-feingold]

@satra sounds good thank you! I'll dig further and see what I can put together

@nicholst thank you for renaming - looks good! Yep our generator accounts for retrospective changes too because the changelog is generated at each merged PR