Use towncrier for changelog generation

[dstansby]

This changes the system of adding changelog entries from updating a single .rst file, to adding individual .rst files to a changes directory. At release time, these are then all automatically collated using towncrier. This has the advantages of:

• Removing potential merge conflicts in releaset-notes.rst during development
• Preventing release notes accidentally ending up in a alread-released section (e.g., see (fix): structured arrays for v2 #2681 where the changelog is in the wrong place)

For the release manager this is not much extra effort. Before, the changelog version already needed manually updating and commiting, with this PR the changelog just needs generating using towncrier and commiting.

Fixes#829

[joshmoore]

Thanks, @dstansby! I love this. A few questions from my side since I've not used it in anger:

• do PRs without a snippet get some form of notification? could they?
• do the snippets get cleaned up? if so, when and by whom?
• is there a sense that we want longer messages now? can they include their own markup?

[jhamman]

One thing I like about our current system is that I can go to the latest changelog to see what is going into the next release. How would we do that using this system?

[dstansby]

do PRs without a snippet get some form of notification? could they?

I put back the PR labeler, which now checks for files changed in /changes, but should otherwise work as before to apply labels to PRs without release note entries.

do the snippets get cleaned up? if so, when and by whom?

Yes, it happens when towncrier build is run. This is done before release (see my changes to the release guide). This collates the fragments into the release notes page, then deletes them.

is there a sense that we want longer messages now? can they include their own markup?

I guess they could do, but they get rendered the same as before (RST lists), so this PR doesn't change how we want to write the messages one way or another.

One thing I like about our current system is that I can go to the latest changelog to see what is going into the next release. How would we do that using this system?

👍 - I altered the readthedocs build to render all the unreleased fragments, so you can see them on the release notes page: https://zarr--2736.org.readthedocs.build/en/2736/release-notes.html

[joshmoore]

I guess they could do, but they get rendered the same as before (RST lists), so this PR doesn't change how we want to write the messages one way or another.

Sounds good, guess we just need to be careful of too complex files that inject chaos into the README. As @d-v-b, I imagine some form of style examples might be worth long-term.

Anyhoo, this rocks.

[martindurant]

Note that #2681 put its note in the right place before merge, but of course that changelog line will need dealing with when this gets merged.

[dstansby]

Since I think I've dealt with all the feedback/suggestions, and there's no objections, should we merge this to avoid stuff getting further out of sync with new PRs?

[dstansby]

This changes the system of adding changelog entries from updating a single .rst file, to adding individual .rst files to a changes directory. At release time, these are then all automatically collated using towncrier. This has the advantages of:

• Removing potential merge conflicts in releaset-notes.rst during development
• Preventing release notes accidentally ending up in a alread-released section (e.g., see (fix): structured arrays for v2 #2681 where the changelog is in the wrong place)

For the release manager this is not much extra effort. Before, the changelog version already needed manually updating and commiting, with this PR the changelog just needs generating using towncrier and commiting.

Fixes#829

[joshmoore]

Thanks, @dstansby! I love this. A few questions from my side since I've not used it in anger:

• do PRs without a snippet get some form of notification? could they?
• do the snippets get cleaned up? if so, when and by whom?
• is there a sense that we want longer messages now? can they include their own markup?

[jhamman]

One thing I like about our current system is that I can go to the latest changelog to see what is going into the next release. How would we do that using this system?

[dstansby]

do PRs without a snippet get some form of notification? could they?

I put back the PR labeler, which now checks for files changed in /changes, but should otherwise work as before to apply labels to PRs without release note entries.

do the snippets get cleaned up? if so, when and by whom?

Yes, it happens when towncrier build is run. This is done before release (see my changes to the release guide). This collates the fragments into the release notes page, then deletes them.

is there a sense that we want longer messages now? can they include their own markup?

I guess they could do, but they get rendered the same as before (RST lists), so this PR doesn't change how we want to write the messages one way or another.

One thing I like about our current system is that I can go to the latest changelog to see what is going into the next release. How would we do that using this system?

👍 - I altered the readthedocs build to render all the unreleased fragments, so you can see them on the release notes page: https://zarr--2736.org.readthedocs.build/en/2736/release-notes.html

[joshmoore]

I guess they could do, but they get rendered the same as before (RST lists), so this PR doesn't change how we want to write the messages one way or another.

Sounds good, guess we just need to be careful of too complex files that inject chaos into the README. As @d-v-b, I imagine some form of style examples might be worth long-term.

Anyhoo, this rocks.

[martindurant]

Note that #2681 put its note in the right place before merge, but of course that changelog line will need dealing with when this gets merged.

[dstansby]

Since I think I've dealt with all the feedback/suggestions, and there's no objections, should we merge this to avoid stuff getting further out of sync with new PRs?

[dstansby]

This changes the system of adding changelog entries from updating a single .rst file, to adding individual .rst files to a changes directory. At release time, these are then all automatically collated using towncrier. This has the advantages of:

• Removing potential merge conflicts in releaset-notes.rst during development
• Preventing release notes accidentally ending up in a alread-released section (e.g., see (fix): structured arrays for v2 #2681 where the changelog is in the wrong place)

For the release manager this is not much extra effort. Before, the changelog version already needed manually updating and commiting, with this PR the changelog just needs generating using towncrier and commiting.

Fixes#829

[joshmoore]

Thanks, @dstansby! I love this. A few questions from my side since I've not used it in anger:

• do PRs without a snippet get some form of notification? could they?
• do the snippets get cleaned up? if so, when and by whom?
• is there a sense that we want longer messages now? can they include their own markup?

[jhamman]

One thing I like about our current system is that I can go to the latest changelog to see what is going into the next release. How would we do that using this system?

[dstansby]

do PRs without a snippet get some form of notification? could they?

I put back the PR labeler, which now checks for files changed in /changes, but should otherwise work as before to apply labels to PRs without release note entries.

do the snippets get cleaned up? if so, when and by whom?

Yes, it happens when towncrier build is run. This is done before release (see my changes to the release guide). This collates the fragments into the release notes page, then deletes them.

is there a sense that we want longer messages now? can they include their own markup?

I guess they could do, but they get rendered the same as before (RST lists), so this PR doesn't change how we want to write the messages one way or another.

One thing I like about our current system is that I can go to the latest changelog to see what is going into the next release. How would we do that using this system?

👍 - I altered the readthedocs build to render all the unreleased fragments, so you can see them on the release notes page: https://zarr--2736.org.readthedocs.build/en/2736/release-notes.html

[joshmoore]

I guess they could do, but they get rendered the same as before (RST lists), so this PR doesn't change how we want to write the messages one way or another.

Sounds good, guess we just need to be careful of too complex files that inject chaos into the README. As @d-v-b, I imagine some form of style examples might be worth long-term.

Anyhoo, this rocks.

[martindurant]

Note that #2681 put its note in the right place before merge, but of course that changelog line will need dealing with when this gets merged.

[dstansby]

Since I think I've dealt with all the feedback/suggestions, and there's no objections, should we merge this to avoid stuff getting further out of sync with new PRs?

[dstansby]

This changes the system of adding changelog entries from updating a single .rst file, to adding individual .rst files to a changes directory. At release time, these are then all automatically collated using towncrier. This has the advantages of:

• Removing potential merge conflicts in releaset-notes.rst during development
• Preventing release notes accidentally ending up in a alread-released section (e.g., see (fix): structured arrays for v2 #2681 where the changelog is in the wrong place)

For the release manager this is not much extra effort. Before, the changelog version already needed manually updating and commiting, with this PR the changelog just needs generating using towncrier and commiting.

Fixes#829

[joshmoore]

Thanks, @dstansby! I love this. A few questions from my side since I've not used it in anger:

• do PRs without a snippet get some form of notification? could they?
• do the snippets get cleaned up? if so, when and by whom?
• is there a sense that we want longer messages now? can they include their own markup?

[jhamman]

One thing I like about our current system is that I can go to the latest changelog to see what is going into the next release. How would we do that using this system?

[dstansby]

do PRs without a snippet get some form of notification? could they?

I put back the PR labeler, which now checks for files changed in /changes, but should otherwise work as before to apply labels to PRs without release note entries.

do the snippets get cleaned up? if so, when and by whom?

Yes, it happens when towncrier build is run. This is done before release (see my changes to the release guide). This collates the fragments into the release notes page, then deletes them.

is there a sense that we want longer messages now? can they include their own markup?

I guess they could do, but they get rendered the same as before (RST lists), so this PR doesn't change how we want to write the messages one way or another.

One thing I like about our current system is that I can go to the latest changelog to see what is going into the next release. How would we do that using this system?

👍 - I altered the readthedocs build to render all the unreleased fragments, so you can see them on the release notes page: https://zarr--2736.org.readthedocs.build/en/2736/release-notes.html

[joshmoore]

I guess they could do, but they get rendered the same as before (RST lists), so this PR doesn't change how we want to write the messages one way or another.

Sounds good, guess we just need to be careful of too complex files that inject chaos into the README. As @d-v-b, I imagine some form of style examples might be worth long-term.

Anyhoo, this rocks.

[martindurant]

Note that #2681 put its note in the right place before merge, but of course that changelog line will need dealing with when this gets merged.

[dstansby]

Since I think I've dealt with all the feedback/suggestions, and there's no objections, should we merge this to avoid stuff getting further out of sync with new PRs?

[dstansby]

This changes the system of adding changelog entries from updating a single .rst file, to adding individual .rst files to a changes directory. At release time, these are then all automatically collated using towncrier. This has the advantages of:

• Removing potential merge conflicts in releaset-notes.rst during development
• Preventing release notes accidentally ending up in a alread-released section (e.g., see (fix): structured arrays for v2 #2681 where the changelog is in the wrong place)

For the release manager this is not much extra effort. Before, the changelog version already needed manually updating and commiting, with this PR the changelog just needs generating using towncrier and commiting.

Fixes#829

[joshmoore]

Thanks, @dstansby! I love this. A few questions from my side since I've not used it in anger:

• do PRs without a snippet get some form of notification? could they?
• do the snippets get cleaned up? if so, when and by whom?
• is there a sense that we want longer messages now? can they include their own markup?

[jhamman]

One thing I like about our current system is that I can go to the latest changelog to see what is going into the next release. How would we do that using this system?

[dstansby]

do PRs without a snippet get some form of notification? could they?

I put back the PR labeler, which now checks for files changed in /changes, but should otherwise work as before to apply labels to PRs without release note entries.

do the snippets get cleaned up? if so, when and by whom?

Yes, it happens when towncrier build is run. This is done before release (see my changes to the release guide). This collates the fragments into the release notes page, then deletes them.

is there a sense that we want longer messages now? can they include their own markup?

I guess they could do, but they get rendered the same as before (RST lists), so this PR doesn't change how we want to write the messages one way or another.

One thing I like about our current system is that I can go to the latest changelog to see what is going into the next release. How would we do that using this system?

👍 - I altered the readthedocs build to render all the unreleased fragments, so you can see them on the release notes page: https://zarr--2736.org.readthedocs.build/en/2736/release-notes.html

[joshmoore]

I guess they could do, but they get rendered the same as before (RST lists), so this PR doesn't change how we want to write the messages one way or another.

Sounds good, guess we just need to be careful of too complex files that inject chaos into the README. As @d-v-b, I imagine some form of style examples might be worth long-term.

Anyhoo, this rocks.

[martindurant]

Note that #2681 put its note in the right place before merge, but of course that changelog line will need dealing with when this gets merged.

[dstansby]

Since I think I've dealt with all the feedback/suggestions, and there's no objections, should we merge this to avoid stuff getting further out of sync with new PRs?

[dstansby]

This changes the system of adding changelog entries from updating a single .rst file, to adding individual .rst files to a changes directory. At release time, these are then all automatically collated using towncrier. This has the advantages of:

• Removing potential merge conflicts in releaset-notes.rst during development
• Preventing release notes accidentally ending up in a alread-released section (e.g., see (fix): structured arrays for v2 #2681 where the changelog is in the wrong place)

For the release manager this is not much extra effort. Before, the changelog version already needed manually updating and commiting, with this PR the changelog just needs generating using towncrier and commiting.

Fixes#829

[joshmoore]

Thanks, @dstansby! I love this. A few questions from my side since I've not used it in anger:

• do PRs without a snippet get some form of notification? could they?
• do the snippets get cleaned up? if so, when and by whom?
• is there a sense that we want longer messages now? can they include their own markup?

[jhamman]

One thing I like about our current system is that I can go to the latest changelog to see what is going into the next release. How would we do that using this system?

[dstansby]

do PRs without a snippet get some form of notification? could they?

I put back the PR labeler, which now checks for files changed in /changes, but should otherwise work as before to apply labels to PRs without release note entries.

do the snippets get cleaned up? if so, when and by whom?

Yes, it happens when towncrier build is run. This is done before release (see my changes to the release guide). This collates the fragments into the release notes page, then deletes them.

is there a sense that we want longer messages now? can they include their own markup?

I guess they could do, but they get rendered the same as before (RST lists), so this PR doesn't change how we want to write the messages one way or another.

One thing I like about our current system is that I can go to the latest changelog to see what is going into the next release. How would we do that using this system?

👍 - I altered the readthedocs build to render all the unreleased fragments, so you can see them on the release notes page: https://zarr--2736.org.readthedocs.build/en/2736/release-notes.html

[joshmoore]

I guess they could do, but they get rendered the same as before (RST lists), so this PR doesn't change how we want to write the messages one way or another.

Sounds good, guess we just need to be careful of too complex files that inject chaos into the README. As @d-v-b, I imagine some form of style examples might be worth long-term.

Anyhoo, this rocks.

[martindurant]

Note that #2681 put its note in the right place before merge, but of course that changelog line will need dealing with when this gets merged.

[dstansby]

Since I think I've dealt with all the feedback/suggestions, and there's no objections, should we merge this to avoid stuff getting further out of sync with new PRs?

[dstansby]

This changes the system of adding changelog entries from updating a single .rst file, to adding individual .rst files to a changes directory. At release time, these are then all automatically collated using towncrier. This has the advantages of:

• Removing potential merge conflicts in releaset-notes.rst during development
• Preventing release notes accidentally ending up in a alread-released section (e.g., see (fix): structured arrays for v2 #2681 where the changelog is in the wrong place)

For the release manager this is not much extra effort. Before, the changelog version already needed manually updating and commiting, with this PR the changelog just needs generating using towncrier and commiting.

Fixes#829

[joshmoore]

Thanks, @dstansby! I love this. A few questions from my side since I've not used it in anger:

• do PRs without a snippet get some form of notification? could they?
• do the snippets get cleaned up? if so, when and by whom?
• is there a sense that we want longer messages now? can they include their own markup?

[jhamman]

One thing I like about our current system is that I can go to the latest changelog to see what is going into the next release. How would we do that using this system?

[dstansby]

do PRs without a snippet get some form of notification? could they?

I put back the PR labeler, which now checks for files changed in /changes, but should otherwise work as before to apply labels to PRs without release note entries.

do the snippets get cleaned up? if so, when and by whom?

Yes, it happens when towncrier build is run. This is done before release (see my changes to the release guide). This collates the fragments into the release notes page, then deletes them.

is there a sense that we want longer messages now? can they include their own markup?

I guess they could do, but they get rendered the same as before (RST lists), so this PR doesn't change how we want to write the messages one way or another.

One thing I like about our current system is that I can go to the latest changelog to see what is going into the next release. How would we do that using this system?

👍 - I altered the readthedocs build to render all the unreleased fragments, so you can see them on the release notes page: https://zarr--2736.org.readthedocs.build/en/2736/release-notes.html

[joshmoore]

I guess they could do, but they get rendered the same as before (RST lists), so this PR doesn't change how we want to write the messages one way or another.

Sounds good, guess we just need to be careful of too complex files that inject chaos into the README. As @d-v-b, I imagine some form of style examples might be worth long-term.

Anyhoo, this rocks.

[martindurant]

Note that #2681 put its note in the right place before merge, but of course that changelog line will need dealing with when this gets merged.

[dstansby]

Since I think I've dealt with all the feedback/suggestions, and there's no objections, should we merge this to avoid stuff getting further out of sync with new PRs?

[dstansby]

This changes the system of adding changelog entries from updating a single .rst file, to adding individual .rst files to a changes directory. At release time, these are then all automatically collated using towncrier. This has the advantages of:

• Removing potential merge conflicts in releaset-notes.rst during development
• Preventing release notes accidentally ending up in a alread-released section (e.g., see (fix): structured arrays for v2 #2681 where the changelog is in the wrong place)

For the release manager this is not much extra effort. Before, the changelog version already needed manually updating and commiting, with this PR the changelog just needs generating using towncrier and commiting.

Fixes#829

[joshmoore]

Thanks, @dstansby! I love this. A few questions from my side since I've not used it in anger:

• do PRs without a snippet get some form of notification? could they?
• do the snippets get cleaned up? if so, when and by whom?
• is there a sense that we want longer messages now? can they include their own markup?

[jhamman]

One thing I like about our current system is that I can go to the latest changelog to see what is going into the next release. How would we do that using this system?

[dstansby]

do PRs without a snippet get some form of notification? could they?

I put back the PR labeler, which now checks for files changed in /changes, but should otherwise work as before to apply labels to PRs without release note entries.

do the snippets get cleaned up? if so, when and by whom?

Yes, it happens when towncrier build is run. This is done before release (see my changes to the release guide). This collates the fragments into the release notes page, then deletes them.

is there a sense that we want longer messages now? can they include their own markup?

I guess they could do, but they get rendered the same as before (RST lists), so this PR doesn't change how we want to write the messages one way or another.

One thing I like about our current system is that I can go to the latest changelog to see what is going into the next release. How would we do that using this system?

👍 - I altered the readthedocs build to render all the unreleased fragments, so you can see them on the release notes page: https://zarr--2736.org.readthedocs.build/en/2736/release-notes.html

[joshmoore]

I guess they could do, but they get rendered the same as before (RST lists), so this PR doesn't change how we want to write the messages one way or another.

Sounds good, guess we just need to be careful of too complex files that inject chaos into the README. As @d-v-b, I imagine some form of style examples might be worth long-term.

Anyhoo, this rocks.

[martindurant]

Note that #2681 put its note in the right place before merge, but of course that changelog line will need dealing with when this gets merged.

[dstansby]

Since I think I've dealt with all the feedback/suggestions, and there's no objections, should we merge this to avoid stuff getting further out of sync with new PRs?