Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Release 1.0 #2443

Closed
6 tasks done
richardjgowers opened this issue Jan 13, 2020 · 36 comments
Closed
6 tasks done

Release 1.0 #2443

richardjgowers opened this issue Jan 13, 2020 · 36 comments
Assignees
@richardjgowers
Labels
release
Milestone
1.0

Comments

@richardjgowers
Copy link
Member

richardjgowers commented Jan 13, 2020 •
edited
Loading

I think we're due another release. I think the only ongoing thing is @lilyminium 's work on docs, so ideally this release captures all changes necessary to the package for their doc work. (ie if this is an awful idea tell me and we can postpone).

Looking at #2303 (esp #2303 (comment) ) it looks like the plan is that this release is called 1.0 and is the last python 2.7 release. Work then continues (supporting only py 3) as 1.x until we finish the annoying API change stuff and we call the result 2.0 (and drop py 2)

following feedback, todo:
@IAlibay
Copy link
Member

IAlibay commented Jan 13, 2020

As previously discussed with @richardjgowers I'd like to at least fix the NCDF reader portion of #2323 and #2327 before release 1.0.

I'll hopefully get this done within the next couple of weekends if that's ok with your schedule?

@richardjgowers
Copy link
Member Author

doeeet

@jbarnoud
Copy link
Contributor

With gromacs 2020 released, I'd like to see #2431 merged before 1.0. Especially as, in the current state there will be unreadable errors as the TPR parser expects a TPR from gromacs 2020-beta that are very different.

@lilyminium
Copy link
Member

Sounds good! Will you be going through and looking at currently open PRs before release? There's some GSOC stuff and I would prefer to have #2408 in the release, as the current ITPParser is very flawed. #2382 would be nice too.

@orbeckst
Copy link
Member

In an ideal world we would have everything ready for 1.0.

But the things mentioned above should be in 1.0 and we also wanted to remove the flags #782 . It would be easier to make this 0.21 and then follow up with 1.0. A release is overdue, and it might as well be 0.21 and then we follow up with 1.0.

Btw, @richardjgowers – you looked at the wrong comment, the last one was #2303 (comment) and the official roadmap is the (ambitious) https://www.mdanalysis.org/2019/11/06/roadmap/.

1.0 will be similar to upcoming 0.21 (i.e., no major annoying API breaks but clean-up and deprecations)

@richardjgowers
Copy link
Member Author

Ok thanks @orbeckst so we'll see what we can get finished in a week or two then make a release, maybe it's 1.0 maybe it's 0.21.

@orbeckst
Copy link
Member

Ok, sounds fair.

@IAlibay IAlibay mentioned this issue Jan 28, 2020
Merged
4 tasks
@xiki-tempula
Copy link
Contributor

xiki-tempula commented Jan 29, 2020 •
edited
Loading

Sorry for trying to rush this in the last minute #2480. I have replaced the distance search with capped_distance, so it should provide a decent speed boost.

I will do the bond search in a later date after I get familiar with #2382 as I don't expect it provide much speed boost.

@IAlibay IAlibay mentioned this issue Jan 29, 2020
Closed
15 tasks
@IAlibay
Copy link
Member

IAlibay commented Jan 29, 2020 •
edited
Loading

@richardjgowers

Re: netcdf it looks like if we aren't going for an API complete version 1.0, the only thing needed here is to remove the degrees keyword on the reader. I'll deal with adding scale_factor support to the writer in a future version.

Additionally, as mentioned in #2479 there's a few things that need to be removed on time for v1.0 (currently making my way through this and will make appropriate PRs over the next few days):

Whole file removal (#2481)

  • core/distances.py
  • analysis/x3dna.py
  • core/log.py
  • core/parallel.py
  • core/qcprot.py
  • core/transformations.py
  • core/units.py
  • core/utils.py
  • core/KDTree.py
  • at least one test from test_transformation.py

Analysis changes

Reader changes (#2481)

AtomGroup stubs (#2562)

  • Remove stubs from core/AtomGroup.py.

Memory reader

  • Remove format keyword from :meth:MemoryReader.timeseries.

Others

  • test_generated_residueselection in test_segment.py
  • FullSelgroupSelection in core/selection.py (PR FullGroup selection keyword removal #2500)
  • instance selector in __getitem__ in :class:AtomGroup core/groups.py
  • test_chainid_quick_select in core/test_universe.py
  • test_segments in core/test_atomgroup.py

Since it doesn't seem clear if we are going for v1.0, I'll start the PRs for these and if they don't lead to anything, we could either keep them around for when we do go v1.0, or just drop em and re-open new PRs next time around?

This was referenced Jan 29, 2020
Merged
Merged
Merged
Merged
Closed
Closed
Merged
This was referenced Feb 7, 2020
Merged
Closed
orbeckst pushed a commit that referenced this issue Feb 13, 2020
@IAlibay
Changes holetraj start/stop/step keywords (Issue #2513) (#2514)
6fa3b6d 
* Fixes #2513
* contributes towards #2443
* Removes support for start/stop/step in :meth:HOLEtraj.__init__.
* Adds a check_slice_indices to the values passed to :meth:HOLEtraj.run.
* changes holetraj start/stop/step keywords
* update CHANGELOG
@orbeckst orbeckst changed the title Release 0.21 (aka 1.0) Release 1.0 Feb 13, 2020
@orbeckst
Copy link
Member

orbeckst commented Feb 13, 2020 •
edited
Loading

The next release will be 1.0 — along the lines of the Roadmap.

One goal is to make the jump from 0.20.1 to 1.0 painless and to avoid breaking existing code as much as possible as 1.0 will be the last version with Python 2 support. Users might have to rely on it for a while (until they get rid of legacy Python 2, which might take a long time in science) so we don't want to additionally burden them with having to rewrite their old code just to run 1.0.

If you want to remove something, try to keep the old thing around but deprecate it in 1.0 (add deprecation warnings and deprecated doc) and schedule it for removal in 2.0 (say it in the warning and add comments to the code for anything that should go in 2.0). Even better: raise an issue to remove the thing and tag it with "remove-2.0".

@orbeckst
Copy link
Member

Just to clarify: The avoid "breaking existing code" mainly referred to things like rewriting analysis classes. All the scheduled 1.0 removals and changes that had been planned for a long time should just go ahead as planned (and indeed have mostly be done already).

@orbeckst orbeckst added this to the 1.0 milestone Feb 13, 2020
This was referenced Feb 28, 2020
Merged
Merged
Merged
@orbeckst
Copy link
Member

We should start changing the 0.21 to 1.0; in particularm, it would be good if the dev docs and the version string started showing 1.0.0-dev.

@richardjgowers
Copy link
Member Author

richardjgowers commented Mar 12, 2020 via email

@orbeckst
Copy link
Member

orbeckst commented Jun 5, 2020

Can we get a 1.0 out?

What is holding us up? It really only should be real bugs or important API decisions, not features/nice-to-haves.

I don't think we want to wait for GSoC projects – they can go in 2.0 (or a 1.x if we do one and they still support py 2.7)

@lilyminium
Copy link
Member

lilyminium commented Jun 5, 2020 •
edited
Loading

The following would be nice to have in 1.0 and are close to done / need review:

There are some old issues in the milestone, are they still applicable?

@IAlibay
Copy link
Member

IAlibay commented Jun 5, 2020

#1738 / #2698 would be nice to get done depending on how large a change it involves. I'll have a dig through later today and see how much needs to be done.

@RMeli
Copy link
Member

RMeli commented Jun 5, 2020

I might have a bit of time for #2698 this weekend if you need help @IAlibay, but if it's not an easy change (they never are ;) ) it might drag a bit longer...

#2694 should be ready too if you want to include the fix only and not @lilyminium's suggestion for a more advanced functionality.

@orbeckst orbeckst mentioned this issue Jun 5, 2020
Closed
4 tasks
@richardjgowers
Copy link
Member Author

I’m going to try and bash out 1.0 this weekend, it’s been far too long.

@IAlibay IAlibay mentioned this issue Jun 6, 2020
Closed
@richardjgowers
Copy link
Member Author

I think re: #206 is Writers need a bit of API love, but that can wait as there's nothing showstopped bad about them right now

I've updated the 1.0 milestone, currently there's 2 PRs waiting, my deprecating Timestep to Writers and Lily's cool attribute error hacks. If anyone wants anything else going in to 1.0 you've got about 24 hrs to make lots of noise (with an associated PR where possible).

@lilyminium
Copy link
Member

If refactored helanal (#2622) is okayed by someone (preferably better at geometry than me) before then, that'd be nice, otherwise it can wait. Thanks for pushing things along @richardjgowers!

@orbeckst
Copy link
Member

orbeckst commented Jun 6, 2020 via email

@hmacdope
Copy link
Member

hmacdope commented Jun 8, 2020

@richardjgowers I know i'm a bit late to the party but thoughts on #2619? Its almost there, if not it can wait for sure. :)

@richardjgowers
Copy link
Member Author

richardjgowers commented Jun 8, 2020 via email

@hmacdope
Copy link
Member

hmacdope commented Jun 8, 2020

No worries :)

@orbeckst
Copy link
Member

I'll update the release docs – that's still manual.

@orbeckst
Copy link
Member

1.0 docs are up at https://www.mdanalysis.org/docs/ – thanks @lilyminium for the face-lift!

@orbeckst
Copy link
Member

We still need the github release.

@orbeckst
Copy link
Member

Do we want to advertise right now or do the 1.0.1 so that Python 2 pip installation works #2736 ?

@orbeckst orbeckst mentioned this issue Jun 11, 2020
Closed
@lilyminium
Copy link
Member

Could you please upload a 1.0 testsuite package to conda-forge @richardjgowers :-)

@richardjgowers
Copy link
Member Author

@lilyminium done!

@orbeckst orbeckst mentioned this issue Jun 15, 2020
Open
@IAlibay
Copy link
Member

IAlibay commented Jun 17, 2020

Should the meta.yaml file under mdanalysis/maintainer/conda/MDAnalysis also have been updated for 1.0?

mdanalysis/maintainer/conda/MDAnalysis/meta.yaml

Line 4 in 329c3fc

version: "0.19.1dev"

@richardjgowers
Copy link
Member Author

richardjgowers commented Jun 17, 2020 via email

@orbeckst
Copy link
Member

orbeckst commented Jun 17, 2020 via email

@orbeckst
Copy link
Member

We can delete

The rest is used in CI.

@orbeckst
Copy link
Member

orbeckst commented Jun 17, 2020 •
edited
Loading

@richardjgowers can you please also put the 1.0.0 release up under https://github.com/MDAnalysis/mdanalysis/releases ? Thanks.

EDIT... I'll quickly do it, the tag is already there.

EDIT: see https://github.com/MDAnalysis/mdanalysis/releases/tag/release-1.0.0

@orbeckst
Copy link
Member

That's actually done.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@richardjgowers richardjgowers

Labels
release
Projects
None yet
Milestone
1.0
Development

No branches or pull requests
8 participants
@orbeckst @jbarnoud @xiki-tempula @richardjgowers @RMeli @IAlibay @hmacdope @lilyminium