New release needed

[bricaud]

The release we get with pypi is 0.5.1 and the version on the master branch is also tagged 0.5.1 even if it has many new features. It confuses people, especially when looking at the doc. People mix the 'stable' and 'latest' tag in the doc. I would suggest to make a new release.
I guess it would solve some of the issues opened. I also had students confused during a course on networks and data science where they use it for their project.
Happy new year! :)

[mdeff]

Indeed, people are confused (e.g., #67 and #68). But making a new release won't solve the issue in the long run. The development version will always be ahead of the stable version. Do you think that bumping the version on the development version would single-handedly fix this misunderstanding?

[scottgigante]

I think it's pretty standard practice to have master reflect the latest stable release and have dev run a different version number (e.g. 0.5.2a0). At present master is 374 commits and two years ahead of 0.5.1, but pygsp.__version__ is the same for both of these.

[mdeff]

Thanks for the inputs. I agree with both of you that the stable and in-development versions shouldn't have the same version number. That was a mistake on my side, I'll fix it next release.

I like the idea of explicitly marking that it is a development version with the dev0 suffix. From Hynek Schlawack, an expert on the topic:

How to set and keep a project’s version is a matter of taste and different solutions. After using a few tools in the past, I’ve resigned to making the in-development version the next version with an .dev0 suffix (e.g. "19.4.0.dev0"). Whenever I publish a new version, I strip the suffix, push the package to PyPI, increment the version number, and add the suffix to the new version. This way in-development versions are easily discernible from both the predecessor and the final release.

[pulquero]

Are there any plans to release master? Pypi version is over 3 years old now, and this issue is over 1 year old. Or is there an alternative to pypi I should be using (e.g. conda) or some fork I should be following?

[mdeff]

There are plans, but as you can imagine, they are slipping... We are still committed to develop and maintain the package. Our idea would be to first merge some long-standing PRs. Nowadays it's pretty easy to install from github: pip install git+https://github.com/epfl-lts2/pygsp.

[pulquero]

I did not know that! Maybe that should be added to the README installation section. Unfortunately, when I tried it with --upgrade it just said requirement already satisfied. I think it is because main branch references 0.5.1 and not 0.5.2-alpha/snapshot or something, which is what the original issue is about. So, your solution would be ideal if it wasn't for that :(

[mdeff]

And there's pip magic for this issue too: pip install --ignore-installed git+https://github.com/epfl-lts2/pygsp. 😉

[pulquero]

You forgot to drop the mike!Awesome.Next you will be telling me that I can specify all this in a requirements.txt...

[mdeff]

In a requirements.txt you'd better pin to a commit (future updates to master will otherwise break your code). You can do it with:

numpy==1.20.0
scipy==1.6.0
git+https://github.com/epfl-lts2/pygsp.git@70f47eaf5d4b521f3247c4f5f10e7df1f39b2b47

[pulquero]

This is certainly going to revolutionise my usage of pip across the board.