We do have a few new features and bugfixes on master so we should cut a new release. Anyone volunteering to be release manager?
I may have some time over the weekend to help with reviews etc.
Do you want to be release manager for this one then? We have a pretty good
and quick process.
On Thu, Jul 23, 2020 at 5:11 PM Kyle Beauchamp notifications@github.com
wrote:
I may have some time over the weekend to help with reviews etc.
โ
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/pymc-devs/pymc3/issues/4026#issuecomment-663063179,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAFETGGOYKQOLFO6VLEPHR3R5BHJ3ANCNFSM4PFQNJ5Q
.
Yeah, I can volunteer as long I get some instruction.
Awesome, appreciate it! @michaelosthege who was the other release manager last time? are there some instructions written down somewhere? Otherwise we should probably start jotting that down.
Alex did v3.9.2. Instructions are here: https://github.com/pymc-devs/pymc3/wiki/PyMC3-Release-Checklist
Perfect. @kyleabeauchamp ideally our process gets better and better documented each time.
If anyone has any critical PRs that need merging before release, we should finalize those today IMHO, otherwise I think we're on track for release.
I added the 3.9.3 milestone to all PRs merged after the previous 3.9.2 release.
@kyleabeauchamp All PRs tagged for this release are merged. You can go ahead and release 3.9.3.
I was drafting a release but I noticed that there are build failures on master: https://travis-ci.org/github/pymc-devs/pymc3/builds/712731940
elif pickle_backend == 'dill':
try:
> import dill
E ModuleNotFoundError: No module named 'dill'
pymc3/parallel_sampling.py:435: ModuleNotFoundError
E pytest.PytestDeprecationWarning: Passing arguments to pytest.fixture() as positional arguments is deprecated - pass them as a keyword argument instead.
OK we have a green build on master again. What is our plan on the various open PRs that have been approved? Do we ask people to update their branches and then merge once green?
OK we have a green build on master again. What is our plan on the various open PRs that have been approved? Do we ask people to update their branches and then merge once green?
Yes. If the PR authors checked the "maintainers can edit" box, you can also do it for them.
Maybe we can also just relaunch the tests jobs on each PR: on the Mauna Loa PR, I just pushed commits without rebasing on master and tests passed, so it should work in most cases ๐
Otherwise, what Kyle suggested sounds good ๐
I just relaunched the Travis jobs on all PRs that could be included in 3.9.3 -- let's see how it goes ๐
I think we already merged everything in we wanted for 3.9.3, let's just push the trigger :).
Yeah, that's also fine by me ๐คทโโ๏ธ
Just an FYI, I just rebased off master several PRs that could be included. Let's see whether the test turn green ๐ฌ
I suppose doc PRs that just need merging after rebasing are fine, but it's easy to get on the treadmill of "just this one more PR" and delay a release.
Release is made: https://github.com/pymc-devs/pymc3/releases/tag/v3.9.3
I got an email notification about a github actions failure. It looks like the github release action was expecting the pypi release to be available for installation, but it was not able to find it. Does that sound familiar?
I got an email notification about a github actions failure. It looks like the github release action was expecting the pypi release to be available for installation, but it was not able to find it. Does that sound familiar?
Yes this happened the last times too. Don't re-trigger the pipeline. PyPI won't accept another upload of the same version number. Just ignore it.
I guess we should take out this installation step then. Though it works for my pyrff package with an even shorter delay..
Thanks @kyleabeauchamp!!
Most helpful comment
Release is made: https://github.com/pymc-devs/pymc3/releases/tag/v3.9.3