Hi all, there is one more PR I want to land in 2.7.0 to make the new description feature safe and complete. See discussion here https://github.com/tox-dev/tox/pull/495 Cheers, Oliver On Mon, 27 Mar 2017 at 23:12 Oliver Bestwalter <oliver@bestwalter.de> wrote:

Hi,

version with amended changelog is uploaded. I also added a way to refer to a pull request in the changelog now, as #450 did not have an issue associated: https://github.com/tox-dev/tox/commit/b65bd72533fabcf68d73c9e61c3236a0cd9bf8...

Cheers, Oliver

On Mon, 27 Mar 2017 at 22:53 Oliver Bestwalter <oliver@bestwalter.de> wrote:

Hi Florian,

On Mon, 27 Mar 2017 at 22:47 Florian Schulze <fschulze@fastmail.fm> wrote:

...

#450 isn't in the changelog of the link you sent.

oh right did not add that to the changelog yet. Will do that right away.

...

Where is the magic for the issue linking? I'd like to add it to devpi.

linking code is here: https://github.com/tox-dev/tox/commit/98b6a9c12cd00b8e7b8d71a6ad4bd7c91df426...

Cheers, Oliver

For the next release, I suggest going back to using dev versions (this will be automatic when setuptools_scm is merged) and always pushing one or two dev versions to pypi before an actual release. This makes it easy to decide in which CI chain I like to be adventurous and always use the tox dev versions by default by installing tox with `pip install --pre tox` instead of having to point it at a special dev index (that might change, if somebody else prepares a release from their dev index).

I will integrate using the --pre versions of tox into our CI at work then, so that I don't even have to think about it anymore.

My goal is to reduce the effort of making releases while still having a decent level of exposure of dev versions to real world applications in an as automatic as possible manner. If a handful of people activate that in their company CI configurations, travis.yml ... wherever, we might catch a few bugs before a release without having do too much manual coordination.

Would that be ok?

Do you plan to only upload release candidates as dev releases, or more frequent? I'd be fine with the former, but I don't like if PyPI is spammed with dev releases. I mean devpi was created for this exact use case. And I don't see much difference in installing with "pip --pre" versus "pip -i ..." on a CI. Regards, Florian Schulze

Hi all, the current build seems fine to me, so I would like to push that to pypi tomorrow evening if nobody objects. BTW: I am wondering if it might be better to track releases on the issue tracker as well, as this would get more visibility there ... Cheers, Oliver On Sat, 1 Apr 2017 at 21:58 Oliver Bestwalter <oliver@bestwalter.de> wrote:

On Sat, 1 Apr 2017 at 18:16 Florian Schulze <mail@florian-schulze.net> wrote:

Do you plan to only upload release candidates as dev releases, or more frequent? I'd be fine with the former, but I don't like if PyPI is spammed with dev releases. I mean devpi was created for this exact use case. And I don't see much difference in installing with "pip --pre" versus "pip -i ..." on a CI.

I was thinking only of release candidates and pushing them to pypi instead of devpi as that removes the dependency from another service that has to be up, if people add it to their CI settings. But if devpi.net is meant for this kind of thing and is reliable enough, let's leave the pre releases on devpi and only push the actual releases to pypi.

Cheers, Oliver