Next release: tox 2.8

[obestwalter]

The merged PRs are starting to pile up again so I would like to cut a new release. Trying to organize this with an issue and a project this time, just to see how that goes.

Project is here: https://github.com/tox-dev/tox/projects/6

[The-Compiler]

FWIW I tried the current git master with qutebrowser and pytest. Having some issues with pytest's testsuite, but probably nothing related to tox.

[obestwalter]

This weekend I will prepare an rc as suggested in #541 and let that sit for a week or so and then do the release.

[nicoddemus]

@obestwalter please make sure to share your experience, we are considering doing the same for pytest. 😁

[obestwalter]

sure thing @nicoddemus :)

[obestwalter]

rc1 is online - there are some bumps still I need to iron out (like next time I should update the CHANGELOG to the version and then replace it when rc turns into actual release) - but this should suffice for the first try.

You can install release candidates via:

pip install --pre -U tox

Right now the process is even more involved than before because I like to use the devpi cloud testing I adopted from Bruno and the devpi push is not working for me with the current release, so I used twine for now to upload the files directly from dist/

I prepared a little checklist for myself for the release process which looks like this atm:

# Release Checklist

## PREP

* Make sure CHANGELOG contains all changes
* Add release date
* Add version (or remove rcV suffix)
* Make sure all is committed and pushed

## Tag and upload to devpi

tag version number in format `X.Y.Z[rcV]` - e.g. 2.13.0rc1:

    git tag <version>

upload it:

    devpi login obestwalter
    devpi use devpi use https://devpi.net/obestwalter/dev
    devpi upload

## Test the package

### Locally

    $ vwon tmp
    $ pip install --pre -i https://devpi.net/obestwalter/dev -U tox

Test it.

### With devpi-cloud-test

    $ pip install git+git://github.com/obestwalter/devpi-cloud-test.git@master
    $ git clone git@github.com:obestwalter/devpi-cloud-test-tox.git
    $ cd devpi-cloud-test-tox
    $ dct trigger <version>

Check results at https://github.com/obestwalter/devpi-cloud-test-tox

## Push package to pypi

relevant `~/.pypirc` fragment:

    [distutils]
    index-servers=
        pypi

    [pypi]
    ; WARNING only leaving repository key unset seems to work nowadays
    ;repository=https://pypi.python.org/pypi
    ;repository=https://upload.pypi.io/legacy/
    username=oliver.bestwalter
    password=<secret>

### Upload dist with twine

    $ pip install twine
    $ twine upload dist/*  # (or fetch from devpi if removed already)


### Devpi way (seems broken atm)

This borks out the homepage instead of uploading it atm, no error but no upload either

    $ devpi push tox==<version> pypi:pypi

Quite a fuss still, but I'll get there.

[obestwalter]

2.8.0rc2 is online - if there are no surprises this will be released in a few days.

[gaborbernat]

how are we progressing with this? 👍

[obestwalter]

Let's ship it.

[obestwalter]

Done.

[obestwalter]

I would like to release a bugfix release soon incorporating #599

I would appreciate reviews but feel confident enough to push this out tonight as a quick fix for a bug that might affect a substantial number of installations.

[obestwalter]

Did not feel confident enough yet, after all, should go out today anyway.

[obestwalter]

Litte post mortem on this:

We used rcs ant they did not save as from the bug we introduced. We fixed that bug quite quickly though ober the slow CI weekend :)

I think for now, that rc are an unnecessary complication and that it is better to release much more often and fix bugs quickly, when they pop up.

[ssbarnea]

I think that doing prereleases (dev) builds of PYPI should be a good enough process as few project can use gates on pre-released pypi requirements and spot errors before they break their own product.

So, from my point of view: any tox build that passed its own gates should be made public and be installable using pip install --pre tox.

[obestwalter]

So, from my point of view: any tox build that passed its own gates should be made public and be installable using pip install --pre tox.

I don't feel confident enough about this yet, but I have that in the back of my head for the midterm also. I think for now it's a good strategy to do frequent small releases and fix any problem that might pop up quickly. We already working on improving the tests and the coverage also, so I am pretty optimistic that we can do this continuos deployment kind of thing in the not so far future.