Thinking more about the automation, I think we need to have the
release be 100% automated. Right now it is 90% automated (not counting
the problem of fixing blocker issues).
Oscar, it will be a good idea to make a note of anything in the
release process that isn't automated that should be. One thing I
forgot about is the release notes. It looks like you already added the
deprecations. We should figure out how to automate that. Maybe the bot
can do it. The highlights can't be automated because they are human
curated, so I think that means those should just be removed. Unless
there is some way we can do it with the bot as well (maybe by letting
people tag a PRs notes as a "highlighted note"?).
The AUTHORS/.mailmap isn't automated either. I think they only way
around that would be to run the authors/mailmap scripts as part of the
Travis tests, so that we require any PR with a new new author or new
git metadata to update those files. The main problem with that is that
it puts an extra burden on new contributors, by definition. So I don't
know if there's a better way to do it, or if it's worth doing at all.
It isn't difficult to do and it also can be done at any time, not just
during a release. Maybe we could add it to the CI but as an allowed
failure, that way it isn't a requirement to merge, but it will alert
people when it gets out of date.
The actual updating of files isn't automated right now, which is on
purpose. But I think we need to make it so that the release script
runs on a CI. It already runs in a Docker container, so this should
not be hard to do with one of the various CIs that support custom
containers. It would then run as a dry run on every commit. Then when
we want to do a release proper, either beta, release candidate, or
final, we tag a commit and the CI actually uploads stuff when it is
built on a tag. We've used the current release script since 2017 with
1.1, and with the exception of that 1.1 release, we haven't needed any
bugfix releases. So I think it's safe enough now that we can automate
the uploading.
The only other thing I can remember that isn't automated is various
updates that you have to do to the release script, like updating the
tarball whitelist. But if we run the script on CI that will not be a
problem because it will be updated when it needs to be, instead of
when the release happens.
There's might be other stuff that isn't quite automated, but I'm not
remembering it.
Once we have
1. Full release automation, and
2. A consistent set of rules for release blockers,
then at any point of time we can just look at the release milestone.
If it is empty, we can tag a release. If it isn't, we fix or remove
the blocking issues then tag. If it becomes streamlined enough we
won't even have to do beta or rc releases (but that would be down the
road, once we know everything is working well).
Aaron Meurer
> --
> You received this message because you are subscribed to the Google Groups "sympy" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to
sympy+un...@googlegroups.com.
> To view this discussion on the web visit
https://groups.google.com/d/msgid/sympy/CAHVvXxTAbKHtNxvKY%3DiA3QbBUu4OCWrLWzRvvCwVkL1nmhDaVw%40mail.gmail.com.