[pytest-dev] Proposal: use milestones again for features/deprecations/removals

[Bruno Oliveira]

Hi,

We used milestones in the past to track what would go in each release,
including bugs and new features, but we have not been using them anymore
and I think the reason is because we never usually kept that promise: if we
deemed a release should happen soon we just moved all issues forward or
removed the milestone from them altogether.

I propose we start using milestones again, but only for two reasons:

* **internal** planning of new features: we should use milestones as an
internal guide of what *should* go into the next feature release. This is
not a promise to users, only for us to manage what we think should go into
the next release core developer's time allowing. For example, in my mind we
should change the default logging options [1], but this is not really
defined anywhere except in my head. I would like to use milestones to track
that intent.

* **promise** of deprecation and removal of old features: we have been
using a manual deprecation roadmap [2], but the question of how to keep
issues in sync has been nagging in the back of my head. We should track
deprecation and removals in the milestones, but we must be sure to followup
with them before a feature release is complete. It is important to follow
with our policy of deprecation/two minor issues/removal.

The idea is to, before a feature release, we check the the issues assigned
to that milestone:

 * for open features, we can decide to ping the developer if they want some
more time to get that into that next feature release, otherwise we move it
to the next milestone;
* for open deprecation/removal issues, we have to make sure to close them
before moving with the release.

IMHO, milestones should be created only for feature releases; milestones
for minor releases don't make much sense in our current development
methodology: we can issue bug-fix releases as quickly as we want/need to,
so no feature release should really be blocked by a bug, we can always
issue a bug-fix right after a certain bug is dealt with.

This is an attempt to help our planning and strengthen our
deprecation/removal policy.

Thoughts?

[1] https://github.com/pytest-dev/pytest/issues/3013
[2] https://docs.pytest.org/en/latest/backwards-compatibility.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20180105/cc5375ec/attachment.html>