Hi Floris,
i updated the PR at:
https://bitbucket.org/pytest-dev/pytest/pull-request/266/add-a-release-checklist/diff
i suggest you merge it with default and then branch off pytest-2.7 and
bump the version number for the default branch in _pytest/__init__.py to
2.8.0.dev1.
Indeed, the
On 1 April 2015 at 08:21, holger krekel hol...@merlinux.eu wrote:
Hi Floris,
thanks for the summary. Comments inline.
On Tue, Mar 31, 2015 at 23:55 +0100, Floris Bruynooghe wrote:
Hi,
I started doing inline replying but I think it got confusing. I mostly
agree so far, including with
Hi Floris,
thanks for the summary. Comments inline.
On Tue, Mar 31, 2015 at 23:55 +0100, Floris Bruynooghe wrote:
Hi,
I started doing inline replying but I think it got confusing. I mostly
agree so far, including with semantic versioning, but would like to
summarise the usage of branches
Hi,
I started doing inline replying but I think it got confusing. I mostly
agree so far, including with semantic versioning, but would like to
summarise the usage of branches how I think/understand it should work:
Each release has a release/maintenance branch: pytest-2.6, pytest-2.7 etc.
This
Hi committers and friends of pytest :)
to de-monopolize the knowledge of releasing pytest i just created
a PR with a first stab at a release checklist:
https://bitbucket.org/pytest-dev/pytest/pull-request/266/add-a-release-checklist/diff
It doesn't explain how to use ``devpi``, maybe this
Hi,
If we assume that pytest-2.7.X will be bugfix only we could
tie its doc target to latest and ask everybody who does doc enhancements
to target their PRs to latest.
Seems reasonable to me, but what about doc fixes for features which will
be released only on 2.8.0?
This means that even
