You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
To be able to catch incompatibilities in advance we want to run our tests with the master version of Twisted, ideally as a separate periodical job not tied to PRs. Related to #5303 but with a more narrow scope.
The text was updated successfully, but these errors were encountered:
#5303 could serve as an inspiration. It includes the use of cron (the idea here would be for a job that runs on a schedule, not on every pull request).
However, here we only want the latest Twisted, no other dependency, at least for now; and the test for the latest non-final Python version can be moved to this job as well.
We also want to make sure maintainers get a notification, e.g. by email, if it fails.
Having an automated process for this would be ideal, but I should also note that we always provide a week's worth of feedback period after an announcement email for all our downstream dependencies. We sent out an announcement on 8/18 about 23.8.0:
Bug reports during development that we can mark as release blockers would be great, but if all you can do is check that email and do a little manual testing to make sure that we haven't regressed or hold the release to give you an opportunity to fix a bug on your end, we can probably do that.
To be able to catch incompatibilities in advance we want to run our tests with the master version of Twisted, ideally as a separate periodical job not tied to PRs. Related to #5303 but with a more narrow scope.
The text was updated successfully, but these errors were encountered: