new 0.13.0 release

[orbeckst]

Omnibus issue to discuss 0.13.0 release

Using Milestone to track Issues to include

[richardjgowers]

I think we've got enough as is, so I could do this in a few days. Then PCA
and new xdrlib becomes 0.14 with deprecations for the new system (maybe
with some compatible fixes from the new system). Then the new system is
0.15. Thoughts?

On Mon, 28 Dec 2015 20:20 Oliver Beckstein notifications@github.com wrote:

Omnibus issue to discuss 0130 release

• deprecations: Deprecations on all components to disappear or change in Topology Refactor #599
  Deprecations on all components to disappear or change in Topology Refactor #599

Please add as appropriate

—
Reply to this email directly or view it on GitHub
#600.

[orbeckst]

Getting the deprecations #599 in would be good — the sooner the better.
We'll need to go through the list of open issues for 0.13 and check which ones we deem essential and which ones can be retargeted to 0.14.

[dotsdl]

It's up to you @richardjgowers. The deprecations might take more time since we aren't completely finished with issue-363, so we don't absolutely know everything we plan to lose. Then again, we can always deprecate the things we already know are gone, such as all the setters, this release so users have more time to adapt.

[kain88-de]

Are there already alternatives in place for the stuff you want to deprecate?

[orbeckst]

That's a good point although as it looks at the moment, this is more going to be a heads up ("Hey, listen, this will go away in 0.14, mark it in your calendar!") than a deprecation because there won't be an alternative, at least as far as I understand it.

On that note, how unhappy will users be with the changes #599 related to #363 ?

[richardjgowers]

https://github.com/MDAnalysis/mdanalysis/wiki/Issue363-Changes

I started a wiki page for changes, with maybe what is going to be the largest annoyance to people.

[kain88-de]

So my stand on deprecation warnings. Only activate them when an alternative is in place and name the alternative in the warning. Otherwise I would configure my ipython rc to ignore all warnings from MDAnalysis (and forget about it by the next releases and then wonder why stuff just stopped working)

[orbeckst]

Fair enough, @kain88-de. From the wiki page on the Issue 363 changes and the discussion at #411 I don't get yet which breaks can be done with a transition phase and which ones will be a second big API break. @richardjgowers and @dotsdl will have to chime in.

[kain88-de]

Besides the questions about deprecation's I would also say we have enough for a new release. I'm sure people will be happy about the performance improvements.

[kain88-de]

Btw should we add the conda build for this release?

[richardjgowers]

I'd like to add a conda build, we've got a recipe in #571.

I could do a release in a couple of days, and we could put the deprecations in with 0.14 a month later, then 0.15.0 is mainly just the Topology overhaul on its own. Most of the fundamental code is done for the Topology, but I want to spend a while writing tests to make sure everything is 1,000% working.

[orbeckst]

The discussion on deprecations #599 indicates that we really need more time to figure that one out. Let's not bother with deprecations for 0.13.0. We can always do a 0.13.1 for deprecation messages. I'd rather get out a new release — we have a ton of important stuff and I'd rather release early and often than to keep sitting on improvements for a year.

I'd like to focus on which smaller issues really should be addressed ASAP to make it into 0.13. I added conda build to the list but I'd like folks to go through the 0.13 milestone issues. Feel free to add more checkboxes to the top issue if you want to highlight something in particular.

[orbeckst]

I reprioritized a bunch of issues to later mile stones. Please check in

• milestone 0.13 bugfixes (basically, anything minor that we can add later)
• milestone 0.14 (topology refactoring Move from Atom based topology to array based #363 and new XDR lib code rewrite xdrlib #419 as major changes)
• milestone 1.0 (the API-stable release, hopefully in the not too distant future)

if there are any issues that you feel need to be addressed for 0.13.0.

[richardjgowers]

I'm thinking of doing this at the weekend (17th), I'm using the Milestone to keep track of Issues that will hopefully get finished before then

[richardjgowers]

Ok I've created a release-0.13.0-rc1 branch, if someone on macos could test this it would be great, I'm going to push this to pypi Sunday.

[jbarnoud]

I ran the test suite on MacOS X 10.10.5 (Yosemite) with the version of python provided by apple on a clean virtualenv. Everything went fine except for two small issues:

• the six module did not get installed despite being used (see Add six to the requirements #628)
• both MDAnalysisTests.test_distances.TestOpenMP.test_openmp and MDAnalysisTests.test_distances.TestOpenMP.test_serial get executed during the test. They are mutually exclusive (if one pass, the other cannot). On my setup, the test_openmp test fail as openmp is not available. I do not see that problem on Linux or whith Travis so it puzzles me a bit. @kain88-de ?

[kain88-de]

@jbarnoud , six should be installed with GridDataFormats. It has six as a (dependency)[https://github.com/MDAnalysis/GridDataFormats/blob/75ae09486c904aab21b601c3bf384ac52dc865bb/setup.py#L30]

For the test I can't say. i have openmp installed on my laptop and right now no machine without it. So I'm not sure what happens. My guess would be that the tests can't make the correct decision if a test should be run or not.

[kain88-de]

the tests also pass if I disable openmp with MDA_USE_OPENMP=FALSE pip install package/

[richardjgowers]

@jbarnoud thanks for finding the openmp test. It currently has to have openmp for the test to pass, which is a mistake.

@kain88-de if the flag you're using disables openmp then you should get the test failing too?

[kain88-de]

Well I introduced the flag in #471. This should disable openmp I'll have a look into it.

[richardjgowers]

There's these two attributes which say if the c file was compiled with/without the openmp stuff, these are hidden behind an #ifdef in the C

In [2]: mda.lib.c_distances.OPENMP_ENABLED
Out[2]: False

In [3]: mda.lib.c_distances_openmp.OPENMP_ENABLED
Out[3]: True

[kain88-de]

OK I found it. The problem is how the envoronment flag is parsed. The variable is read as a string. which means it evaluates to true all the time.

[richardjgowers]

13.0 is released to pypi, docs uploaded, conda build still to do

[orbeckst]

Many thanks!!

[dotsdl]

Awesome! Thanks @richardjgowers!

[orbeckst]

Everything else will go into 0.13 bugfixes. In particular the new xdrlib #441 does not change anything from the user side (I think...) so we can put this in 0.13.1; similarly, hopefully 0.13.1 will be the first one to also be released for conda #608.

[richardjgowers]

I'm still planning on putting 0.13.0 on conda, just I have to do some reading to figure out how it all works.

[orbeckst]

On 17 Jan, 2016, at 11:16, Richard Gowers wrote:

I'm still planning on putting 0.13.0 on conda, just I have to do some reading to figure out how it all works.

If you have to change a single line to make it work then it has to be 0.13.1 anyways. And I would put a note in the CHANGELOG and in the docs... and that makes it 0.13.1. I don't think that there's anything wrong with releasing a 0.13.1 within a few days except that we want sufficient confidence that the XDR stuff is holding up in practice.