Fmriprep: Question: workflow for releases?

[jdkent]

I really like how fmriprep does releases:

• linking the updated zenodo
• Giving a list of contributions (and who opened the pull request)
• Having a title for each release

I feel like there are a few manual steps that I don't know how to do. Maybe it would only benefit me, but I think it would be really awesome if one of the upcoming releases was screen recorded so it could be seen how it's done. (Or some other way of communicating the steps if that's easier)

Thanks!

[emdupre]

This is likely (at least) slightly different, but tedana's release checklist was inspired by fMRIPrep and so might be helpful !

We could add something similar to fMRIPrep's docs if there's interest !

[effigies]

Yeah, we don't have it written up, but it's pretty simple, and actually less effort than the following makes it sound:

1. We use release-drafter to automatically generate the changelog.
2. When it's time to release, I copy that into CHANGES.rst, cleaning up any entries for clarity, grammar, etc., and sorting types of change into [FIX,ENH,DOC,RF,TEST,MAINT,CI], but otherwise maintaining order.
3. Commit [skip ci] REL: <version>
4. Signed and annotated tag (we don't always do this step, but it appears to help with between-release versioning)
5. Reformat the changelog entry into a release on GitHub
6. Once the Zenodo entry is created, I manually copy the DOI badge to the top of the GitHub release.

Docker and PyPI pushes are entirely done on CircleCI:

https://github.com/poldracklab/fmriprep/blob/f77f6171976ea28572604545ea0e845b8db83573/.circleci/config.yml#L676-L725

A lot of this could be scripted, using hub and the Zenodo REST API, but I think we're still in the phase where the total time to do it manually is less than the time needed to automate it.

[jdkent]

Thanks you both @emdupre and @effigies for your excellent answers! I fumbled around (made some mistakes), but I think going forward I got it.

@emdupre that documentation was very helpful to me, thanks! I would vote to put it into the fmriprep documentation, even though (as is noted in the tedana documentation) that it is only immediately relevant to the maintainer(s) of that package, it does provide a framework to join in and start making (and releasing) your own stuff.

And it would help future maintainers if the group grows and/or if there is a handing off of the torch.

[effigies]

@jdkent I think that's a great idea. Probably the best place for this is in the Contributing to FMRIPREP section, or possibly adding a "maintainers" section.

[emdupre]

We made our RTD contributing section into a high level overview of our development philosophy, which I've found very helpful -- even just to write ! If there's interest in writing a similar section for FMRIPREP (maybe under the name "maintainers" !), I think it's quite nice to have there :+1:

Pinging @KirstieJane since she helped write quite a lot of the development philosophy and may have thoughts on how to get started with it for FMRIPREP, if that's the direction you decide to go !

[effigies]

@emdupre :+1: on that idea.

I've started a Google doc (fMRIPrep development and maintenance guide) where we can generate some content before we decide exactly how it will fit into the existing docs. Not sure how quickly we'll iterate, but if anybody feels inspired to take a stab, go for it.

cc @oesteban @chrisfilo

[chrisgorgo]

Great initiative - I left some comments.
Best,
Chris

On Wed, Nov 14, 2018 at 7:55 AM Chris Markiewicz [e-mail]
wrote:

@emdupre https://github.com/emdupre 👍 on that idea.

I've started a Google doc (fMRIPrep development and maintenance guide
https://docs.google.com/document/d/1u8d1hi4bk09YsXmi0s8qYJEhxI9cQE7IMoso1M9swqU/edit)
where we can generate some content before we decide exactly how it will fit
into the existing docs. Not sure how quickly we'll iterate, but if anybody
feels inspired to take a stab, go for it.

cc @oesteban https://github.com/oesteban @chrisfilo
https://github.com/chrisfilo

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/poldracklab/fmriprep/issues/1386#issuecomment-438712657,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAOkp3xgtE_GFx5WNSAa_t8Lwb-nfdUkks5uvDzZgaJpZM4YbwhW
.