search

haddocking / pdb-tools

A dependency-free cross-platform swiss army knife for PDB files.
https://haddocking.github.io/pdb-tools/
Apache License 2.0
378 stars 113 forks source link

Update PyPI version #42

Closed joaomcteixeira closed 4 years ago

joaomcteixeira commented 4 years ago

A user just reported #41 which is a duplicate from #39, meaning that updates in the master branch are not getting reflected directly in the PyPI package.

Please update the PyPI package with the new version. Because it is a fix without breaking backwards compatibility nor new feature addition, I propose next version number to be 2.0.1 to account for the PR #40 . As far as I can see this is the only PR accepted since 2.0.0 release.

mtrellet commented 4 years ago

Good point! I think only @JoaoRodrigues has the maintainer rights to do such release, right?

JoaoRodrigues commented 4 years ago

Thanks for the detective work! Will have a look this afternoon!

JoaoRodrigues commented 4 years ago

I'll make a new release then, 2.0.1.

Moving forward, what do you think we should do in these situations? It's not very practical to have a release for every commit we make.

amjjbonvin commented 4 years ago

Could follow a Gromacs strategy bundling updates into quarterly or longer periods periodic releases

And in between people can install / update from git - provided clear instructions are provided

joaomcteixeira commented 4 years ago

It's not very practical to have a release for every commit we make.

On the contrary. Actually we should to: "Further, we use semantic versioning to indicate compatibility between releases with the same major version." Each accepted PR should be followed by a respective bumpversion (with tag). Then it is easy, release to PyPI are two twine commands.

The strategy @amjjbonvin suggested is also nice, though I have to suggest otherwise because pdb-tools is a project of small magnitude which ecosystem relies more on agile development than large-scale changes.

These are my thoughts according to my current knowledge. I follow this strategy in other projects with very nice results so far.

JoaoRodrigues commented 4 years ago

Nice input from both, thanks!

Here's my suggestion then: for every PR/patch/bug fix we bump the last number, for every new feature we bump the middle one, and for large changes that break compatibility we bump the first. So, next bug fix would be 2.0.2, if we added a new script we'd bump to 2.1, and if we decided to rewrite everything in Rust we'd go for 3.0.0. How does this sound?

joaomcteixeira commented 4 years ago

That is exactly what Semantic Version 2.0 states: https://semver.org/#semantic-versioning-200

you don't need to to go to 3.0.0, because 2.0.0 was just released and got patched to 2.0.1, still follows semantic versioning, so we just need to restate our version rules.

The only reason I am referring so much to SV2 is because we stated that in the paper. But we can always say, after version X we follow other rules.

JoaoRodrigues commented 4 years ago

OK :)

We should add this to our PACKAGING.md rules.

EDIT: It was there already. I just added a clearer notice to update version numbers explicitly.