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.