Cutting a new release

[athornton]

The subprotocols fix hasn't made it into a release or a PyPi package. Please publish a new release and upload to PyPi so I can just pip install a packagename instead of from a git repo.

[betatim]

Maybe we can take this as an opportunity to setup some basic travis infrastructure so that future releases just require a maintainer to make a new release on GitHub.

A good contribution for that would be a PR that adds https://docs.travis-ci.com/user/deployment/pypi/ and we'd either need @ryanlovett to then setup his PyPI password as a secure variable in .travis.yml or someone creates a new PyPI account for nbserverproxy which we use.

[ryanlovett]

I'll create a separate PyPI account for nbserverproxy CI and enable it to upload.

[mnlevy1981]

I'll second the request for a new release: in pangeo-data/pangeo#432 we're recommending explicitly requesting nbserverproxy 0.8.3 and tornado 5.0.2 because conda install nbserverproxy provides

$ conda list | grep -e nbserverproxy -e tornado
nbserverproxy             0.8.3                 py37_1000    conda-forge
tornado                   5.1.1            py37h470a237_0    conda-forge

out of the box and that doesn't work for forwarding the dask dashboard through http://localhost:8888/proxy/8787/status. (I'm not sure if conda ties in to the PyPi structure / TravisCI automation or if it's another avenue to installing which needs to be updated.)

[ryanlovett]

I've pushed out 0.8.4.

I'll keep this issue open until we address @betatim's suggestion.

• Setup dedicated nbserverproxy PyPI user
• Register repo on travis
• Add tests
• Add travis build config
  • Add nbserverproxy PyPI password as travis secret
  • Run tests
  • Build and upload releases on version bump

Anything else?

[betatim]

I didn't know there was a conda-forge package, is there something we can do to automate updating that when we tag a new release here? Or not worth the effort?

The list looks good.

[ryanlovett]

I've configured travis for pypi deploys, but flubbed my chance on a tagged commit.

I added the need for tests to the list above.

[betatim]

Debugging the PyPI upload process can be a bit tedious, I usually make a release or two marked as pre-release and with a version that ends in rc1 (or rc2) which seems to get ignored by pip when users install things to test that everything works prior to the next real release.

[jakirkham]

Given there have been a couple of releases recently, should this be closed?

[ryanlovett]

The last version bump triggered CI properly and would have uploaded to pypi had I not already done it. Closing.

We need tests though.