release 0.16.2

[kain88-de]

Since it looks like we will have a 0.16.2 release for deprecations we should track it's progress.

Generally I'm for handling this release a little bit different then. I would like that it is minimal and preferable only contains deprecations. My suggestion is to branch of master and create a release-0.16.x branch. We would then make any deprecations on this branch and not in develop. I'll also volunteer to back-port important bugs into the release 0.16.x branch.

The reason is that we soon can't make a release for some time. This will be once we merge #1370 and #1372 then we have to stabilize the tests and python3. This will take some time and people will only have time to work on this either right now (eg @utkbansal ) or next month ( @richardjgowers & @tylerjereddy ). Following my suggestion above would allow us to move fast on these two topics without people being delayed due to a 0.16.2 release.

As a release target I would say end of the month. Until then we can go over the deprecations.

Current issues for deprecations are

• add deprecation warnings for API changes #1403 (instead of add deprecation warnings for API changes #1383)
• update copyright year #1298

edits:

• updated issue list — @orbeckst

Release checklist:

• set release date
• make release
• create online docs for master in https://github.com/MDAnalysis/docs (with ./maintainer/deploy_master_docs.sh from the master branch)
• create zip file of docs and upload to GitHub release page and name it MDAnalysisDocs-0.16.2.zip (see docs tarball missing from 0.16.0 release #1353 )
• pypi release
• conda release (automated on conda-forge)
• release notes page on wiki
• tweet
• blog

[orbeckst]

I don't understand why you want to branch 0.16.2 off master. Looking at CHANGELOG we have a few fixes that fit nicely into a 0.16.2.

Why not add the deprecations on top of that and call it done?

EDIT: ... and such a 0.16.2 could be done by the end of the week.

[kain88-de]

If you can do a release by the end of sunday that is OK too.

[richardjgowers]

Yeah I don't see the real gain in doing multiple branches for this. We can just hold off on merging anything big until we push out the deprecations.

[kain88-de]

We can just hold off on merging anything big until we push out the deprecations.

That is the thing. the pytest transition and python3 aren't big PR's they are a whole bunch of small PR's and @utkbansal can only do the work he is being paid for when we merge his PR's.

[richardjgowers]

@kain88-de ok yeah, I see your point.

https://datasift.github.io/gitflow/IntroducingGitFlow.html

You're proposing something like this? So we merge 0.17 things to one branch, and other things to a 16.x branch?

[orbeckst]

We could do a release branch for this release; just be careful with naming so that it does not collide with the release-0.16.2 tag...

(Historically, GitFlow used to be, more or less, the model that we had adopted for MDAnalysis. That's why we have develop and master and why we merge feature branches into develop. However, we (and others, if you look around) found that following this model too rigidly was too burdensome and with good CI, doing release branches etc was not really necessary.)

[kain88-de]

My idea was we use the following model for the 0.16.2 release only due to special circumstances.

git checkout master
git checkout -b release-0.16.x
# do changes as backports
git checkout master
git merge release-0.16.x
git tag release-0.16.2
git branch -D release-0.16.x
git merge develop
git tag release-0.17.0

but if we get the deprecations right until sunday with a release we don't need to do that. Depending if @richardjgowers is OK doing a release tomorrow.

[kain88-de]

OK so the copyright year is done. The only thing left for the release are the deprecations. Could be do a slight change from my plan above and branch of develop now? It's basically the same plan as above we just start from the develop branch. I think the overhead is also small since we only add 1 commit/PR to develop after branching off.

@richardjgowers are you OK with this plan?

[orbeckst]

I would also like to add PR #1404 (issue #1159) – the PR is done and just needs a final review.

[orbeckst]

Btw, PR #1370 was merged and it didn't break everything (maybe clicking on files in coveralls is broken but I don't know if this has been broken for a while). Right now #1370 will show up in 0.16.2, at least if we branch of develop.

[kain88-de]

I suggest we branch of here. This is one commit before #1370. We then merge #1404 and #1403 into the new branch and make a release. To have the history of these changes also in develop (for the CHANGELOG file) I would cherry-pick those changes into develop after the release (most likely just the CHANGELOG entries).

[kain88-de]

@richardjgowers you said you are busy at work right now. When is the earliest you can commit time ot make a release?

[richardjgowers]

@kain88-de this weekend?

[kain88-de]

weekend sounds good

[richardjgowers]

Ok I'm a little confused about this release. If we're doing it this weekend, why do we need PR #1421, (ie why can't we take the snapshot of develop at that point) and why can't PR #1427 also go into 16.2?

[kain88-de]

You can also branch off develop on Sunday. But you will have to adjust the test suite setup.py to install pytest as well. In general I thought I would try and keep the pytest stuff out of this release.

[richardjgowers]

ah right, I didn't realise we were avoiding pytest in 16.2...

[kain88-de]

Yeah you told me you are always careful with releases. I'm just trying to just that. If you feel comfortable including the pytest transition halfway go ahead.

About #1427 i can arrange to include it in the release as well.

[richardjgowers]

Maybe it's not correct, but the tests aren't user facing, so it doesn't matter what state they're in between releases?

[utkbansal]

Doesn't sound like a good idea to have a fragmented test suite in a release.

[kain88-de]

They are a user facing change in the MDAnalysisTests package and @orbeckst is usually quite happy to be able to tell users they can just run to test to confirm their installation work.

[utkbansal]

@orbeckst is usually quite happy to be able to tell users they can just run to test to confirm their installation work.

Totally agree, even explaining how to run this is a bit difficult. You have two long commands and a lot of dependencies added.

And if we are going to do this, then at least we should write a bash script or something to run the test easily.

[richardjgowers]

ok release is on pypi

[kain88-de]

The source is not on pypi.io

https://pypi.org/project/MDAnalysis/0.16.2/#files

[richardjgowers]

Ok, source should be up now

[kain88-de]

I'm sorry I still only see the egg file.

[richardjgowers]

I'm not sure what the site you linked is, is it still in beta?

https://pypi.python.org/pypi?:action=display&name=MDAnalysis&version=0.16.2

[kain88-de]

I linked to the new pypi warehouse. conda-forge pulls the sources from their. On that site I do only see the egg's so far.

[kain88-de]

maybe I also have to wait some time

[kain88-de]

OK looks like I can download the file. It't not shown yet on the website. So I guess waiting for pypi to update their own cache

[kain88-de]

conda packages are updated

[kain88-de]

OK i've done everything I could now for the release. @richardjgowers or @orbeckst have to do the docs.

[orbeckst]

I pushed the master docs and created the GitHub release https://github.com/MDAnalysis/mdanalysis/releases/tag/release-0.16.2 together with the zip file of the docs.

Note for the docs:

export GH_TOKEN=<secret>
pushd package
python setup.py build_ext --inplace
python setup.py build_sphinx
pushd doc/html/html
zip -r ../MDAnalysisDocs-0.16.2.zip .
popd; popd
./maintainer/deploy_master_docs.sh

(and upload package/doc/html/MDAnalysisDocs-0.16.2.zip to the GitHub release page).