+1 from me 2018-01-05 2:12 GMT+01:00 Bruno Oliveira <nicodde...@gmail.com>:
> 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 > > > > _______________________________________________ > pytest-dev mailing list > pytest-dev@python.org > https://mail.python.org/mailman/listinfo/pytest-dev > > -- Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Eric Shander
_______________________________________________ pytest-dev mailing list pytest-dev@python.org https://mail.python.org/mailman/listinfo/pytest-dev
