pdbfixer
pdbfixer copied to clipboard
openmm
Issue a small new release?
I'm working on a project that requires PDBFixer to be conda installable and I would like to pin it to a particular version as opposed to pdbfixer-dev. Specifically, can a release be issued which contains the commit 2cc1516c8245eb8f5e784599fc6a0a76681daae3, this change is fairly important to getting my system to run through PDBFixer.
We'll be putting out a new version of OpenMM very soon (as in, we're working on building a release candidate right now). We'll do a new release of PDBFixer to go along with it.
Also, relatedly, we're having problems with pdbfixer-dev. Specifically, if I conda install --yes -c omnia pdbfixer-dev on OS X under Python 3.5, I get the message:
PackageNotFoundError: Package not found: '' Package missing in current osx-64 channels:
- pdbfixer-dev
Close matches found; did you mean one of these?
pdbfixer-dev: pdbfixer
I also tried conda installing "pdbfixer-dev: pdbfixer" as the above suggests, but that fails as well. And conda install --yes -c omnia/label/dev pdbfixer works properly, and I was under the impression it would pull the latest version from master -- but the version I get seems not to include the key change @limn1 mentioned above (though I do note that the latest dev release IS listed as having been built on Dec. 6, so it's unclear to me what's going on).
What am I doing wrong? Thanks.
@peastman @jchodera - any insights? We still have this same issue with pdbfixer-dev.
I think @peastman plans to release another update as soon as OpenMM 7.1 is officially released (likely Friday).
I just created the github release. What's needed to generate a new conda build?
Update the conda recipe to pull the new version tag, I believe.
On Fri, Feb 3, 2017, 4:27 PM peastman [email protected] wrote:
I just created the github release. What's needed to generate a new conda build?
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/pandegroup/pdbfixer/issues/147#issuecomment-277399888, or mute the thread https://github.com/notifications/unsubscribe-auth/AGzUYegTLgd9wYW0DHopyBvLGd5FdMhdks5rY8YPgaJpZM4LsruY .
I just created a PR for a release: https://github.com/omnia-md/conda-recipes/pull/693
What do you think about sticking to x.y.z version numbers in the future? It's a bit weird to keep alternating between x.y and x.y.z, and I'm not totally sure that will behave as expected when bugfix releases are made.
Sure, that's fine. Also, it's ok for __version__ to say 1.4 but conda to say 1.4.0. I don't think that will confuse anyone.
Sure, that's fine. Also, it's ok for version to say 1.4 but conda to say 1.4.0. I don't think that will confuse anyone.
That would confuse even me. Let's do this going forward, but not change things right now if you don't want to reissue a new release and fix tags.
@peastman : I don't think moving the 7.1.0rc1 package to the main channel is going to cut it. I think we need to bump the version to 7.1.0 and rebuild. Otherwise, I don't think specifying >=7.1.0 as a version number is going to work.
See the problems we're having with the pdbfixer recipe: https://github.com/omnia-md/conda-recipes/pull/693
Also, there's inconsistency in tag names: This one is 1.4, but the last releases were all prefixed by v as in v1.3. Maybe we can standardize this?
Note that we also just switched labels for the last release, and that didn't cause any problem.
That seems to do the trick, but it is going to be pretty hard to explain why everyone should be using >=7.1.0rc1 for all their tools that rely on openmm instead of >=7.1.0.
Can't we rebuild the openmm package with 7.1.0 as the label and verify no files differ from 7.1.0rc1 except those with the tag?
Note that we also just switched labels for the last release, and that didn't cause any problem.
We had both a 7.0rc1 and a 7.0.1. These version numbering inconsistencies don't exactly project professionalism from our end.
@peastman: Looks like the conda release is ready to go. Just wanted to double-check to see if you wanted to rename this to 1.4.0 instead of 1.4 for consistency, or what you thought about rebuilding an openmm 7.1.0 release so people don't need to build their packages against openmm >=7.1.0rc1.
I'd rather not rename or rebuild any releases. In fact, I'd be fine with just establishing that PDBFixer uses two component version numbers instead of three, and that if we need to fix a bug, we'll call it 1.5.
I'd rather not rename or rebuild any releases. In fact, I'd be fine with just establishing that PDBFixer uses two component version numbers instead of three, and that if we need to fix a bug, we'll call it 1.5.
Sigh. OK.
I'm lodging my formal disapproval for this inconsistent approach to version numbering and trudging ahead reluctantly.
Disapproval noted. :) If you ever figure out a way to fix this without having to rebuild releases, let me know...
Disapproval noted. :) If you ever figure out a way to fix this without having to rebuild releases, let me know...
We've already explained that is not possible.
Then complain to the conda developers that they've made an industry standard development best-practice impossible.
You're free to complain here: https://github.com/ContinuumIO/anaconda-issues/issues
I certainly don't have a problem with inserting a separate testing step where, once we settle on a release candidate, we build the actual 7.1.0 release package, test THAT too, and then roll it out by switching channels. That doesn't seem like a crazy burden.
I've created an issue where you'll have to address the inconsistencies in version numbering via documentation: https://github.com/pandegroup/openmm/issues/1733
If by "test THAT" you mean, "Post it for users to try out and wait another week," yes we could do that.
If by "test THAT" you mean, "Post it for users to try out and wait another week," yes we could do that.
Yes! I think that would be a reasonable step to add:
- Build 7.1.0 and put it in the
rcchannel - Have users test it
- Move it to
main
Problems solved!
The other solution would be to leave off the rc in the version number from the start. But then if we needed a second release candidate, we would simply delete the first one, upload the new one with the exact same name, and tell users they need to manually delete and then reinstall. That seems to me like the best solution.
The other solution would be to leave off the rc in the version number from the start. But then if we needed a second release candidate, we would simply delete the first one, upload the new one with the exact same name, and tell users they need to manually delete and then reinstall. That seems to me like the best solution.
I'm fine with that as well.
Ok, let's do that for future releases. And I'll bookmark your comment, because you are almost certainly going to complain when I say to delete a release and post a new one with the same name! So I'll be able to point to where you just agreed to it. :)
It worries me to have two different things with the same name.
@peastman : I don't think your notion of a release candidate is as widely held as you think. https://en.wikipedia.org/wiki/Software_release_life_cycle#Release_candidate
In this stage of product stabilization, all product features have been designed, coded and tested through one or more beta cycles with no known showstopper-class bugs. A release is called code complete when the development team agrees that no entirely new source code will be added to this release. There could still be source code changes to fix defects, changes to documentation and data files, and peripheral code for test cases or utilities
You seem to want a "RTM" build https://en.wikipedia.org/wiki/Software_release_life_cycle#Release_to_manufacturing_.28RTM.29
I suggest we release as many betas as we need, produce a binary called 7.2.0 from a tag called 7.2.0, test it as if it were a release candidate. If it succeeds, release it. If it fails, produce a new binary called 7.2.1 from a tag called 7.2.1 and test it as if it were a release candidate. Market the final product as "OpenMM 7.2". No one will care that we """"skipped"""" (air quotes) 7.2.0
