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
