Update license

[jarrodmillman]

See #199 (comment).

[pllim]

LGTM. I appreciate not deleting Astropy altogether. Thanks!

[bsipocz]

@pllim - out of curiosity, is there a chance to revive the changelog/milestone bot? I miss it very much 😢 :)

[pllim]

Hmm the old changelog format? I think it still runs from https://github.com/pllim/action-check_astropy_changelog but the astropy-bot is dead I think after Heroku got greedy.

[pllim]

I just checked, we're still using it and it seems to be working for us at https://github.com/spacetelescope/jdaviz/blob/2093786ca917546e6fb7c459a6903b6df4367885/.github/workflows/changelog_check.yml#L17

[jarrodmillman]

We (mostly @lagru and @stefanv) are working on something similar (I think) for scikit-image and plan to use for release notes and ading milestones. We should coordinate!!

This will be pulled out of scikit-image and made into a installable tool soonish:

• Rework generate_release_notes.py and add PR summary parsing scikit-image/scikit-image#6961

We are using it along with:

• https://github.com/scientific-python/attach-next-milestone
• https://github.com/scikit-image/scikit-image/blob/main/.github/workflows/milestone-merged-prs.yaml
• https://github.com/scikit-image/scikit-image/blob/main/.github/workflows/label-check.yaml

The tentative plan to use it for a bunch of projects (networkx, scikit-image, napari) that are already basically using something like the new tool (due to copying from one another) and other projects I am releasing (pygraphviz, numpydoc, and a bunch of little tools living here.

[bsipocz]

I just checked, we're still using it and it seems to be working for us at https://github.com/spacetelescope/jdaviz/blob/2093786ca917546e6fb7c459a6903b6df4367885/.github/workflows/changelog_check.yml#L17

Wonderful, thanks (I've just ping William about it). If you are really that eager to get rid of it, you know a possible place to upstream :)

[pllim]

I'll definitely be happy to upstream https://github.com/pllim/action-check_astropy_changelog if you find it useful though I'd rather it doesn't go through a radical refactoring because I don't have time to fix stuff downstream that uses it. Feel free to open issue there if Scientific Python is serious about this. 😄

Interesting to see other efforts along this line somewhere else. astropy is also rethinking such things over here:

• Discussion of the consistency checks astropy/astropy#14897

[bsipocz]

@jarrodmillman - I'm happy to coordinate, but would very much like to keep this changelog format for these projects. They are too small for towncrier, and the system worked really well. Assuming some bots/actions are in place, otherwise things need to be cleaned up after releases (I had to fix the consistency of a few, long-merged PRs here last night).

Also, I have very strong opinions about the changelog, that not all PRs should be listed in it (unlike the github release notes), but it could be one-liner mention of user-facing changes. And not everyone agrees with this, which is fine.
I also like to use milestones, I find them extremely useful to figure out which release a given PR went into.

[stefanv]

The tool Lars is working on uses labels to decide what goes into the release notes and under which heading. We also plan to scrape release note messages from a fenced code block in the PR description.

The milestone attacher helps us to ensure that all PRs have a milestone, and the label checker does the same for labels.

Of course, everyone should use whichever tool and workflow work best for them :)

[bsipocz]

Interesting. So you don't milestone PRs before they are merged, only after? I think this could work very nicely with all the linear projects I have, no more remilestoning unfinished stuff, etc.

With this approach, do you keep track of release blockers with labels, or manually milestone them?

[stefanv]

We just started using this a week ago, so we're still feeling it out.

But, yes, we milestone upon merge with the action, and also milestone manually items we'd like to include in the release. Anything not merged in that release gets moved to the next milestone.

I can imagine some projects not wanting the action to overwrite existing milestones, so I could add an option for that.

[bsipocz]

Sounds excellent. I'll open a follow-up issue for that in https://github.com/scientific-python/attach-next-milestone, and will opt in using it along with @pllim's changelog checker with doctestplus in the CI refresh PR I'm planning to open.

With that said, I'm going ahead and merge this and the other PR, I'm sorry for the side tracks.