[Matplotlib-devel] 2017-05-08 phone call

- Went over the last few issues for 2.0.2 (which has subsequently been tagged and released)

- discussed future release plans

Going forward, we do not plan to do a 2.0.3 (unless we find another truly egregious regression) and plan to get a 2.1 RC in time for scipy (July).

This leaves the question of what to do with our milestones as we have 600+ things tagged for 2.0.3. In general, we need some way to differentiate 'This must go in for this release X.Y.Z' and 'This can / sholud be merged / backported for release X.Y.Z'.

Maybe we should have a 'next minor' and 'next patch' milestones to hold the 'can/should' issues / PRs and use the explicitly numbered milestones for the 'must' category?

Re: 2017-05-08 phone call

- Went over the last few issues for 2.0.2 (which has subsequently been tagged and released)

- discussed future release plans

Going forward, we do not plan to do a 2.0.3 (unless we find another truly egregious regression) and plan to get a 2.1 RC in time for scipy (July).

This leaves the question of what to do with our milestones as we have 600+ things tagged for 2.0.3. In general, we need some way to differentiate 'This must go in for this release X.Y.Z' and 'This can / sholud be merged / backported for release X.Y.Z'.

Maybe we should have a 'next minor' and 'next patch' milestones to hold the 'can/should' issues / PRs and use the explicitly numbered milestones for the 'must' category?

How about labels for priority or importance instead of milestones? I really don't like the idea of multiple concurrent milestones for a single release.