+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

Reply via email to