Repository navigation
Release Schedule 1.5 #4744
Description
As my first time going through a point release, and with less than two weeks until 1.5, I wondered about the release schedule. As the mailing list has gone down, I started an issue to discuss this.
I presume it will go something like:
- a v1.5 branch gets created from master, i.e. we implement a code-freeze for 1.5
- we then start removing commits from the 1.5 branch that we don't consider stable, i.e. things in master that we discover aren't as stable as we thought when we first merged them and thus needs holding back until v2.1.
- once we feel confident about the 1.5 release, we release.
So question, when does step 1 occur, and how long between step 1. and step 3.?
Activity
jenshnielsen commented on Jul 19, 2015
I don't think we want to do step 2. We branch and then we stabilise the new branch possibly disabling stuff that don't quite work. IMHO the main point of the release cycle is to cut some RCs and get wider testing of those
OceanWolf commented on Jul 19, 2015
yes, I basically meant it like that (perhaps with a couple of days between branching and RC to let things settle).
I basically ask as we have a milestone of a fixed day for 1.5, despite it taking time to go through RC steps etcetera beforehand...
tacaswell commented on Jul 20, 2015
We don't usually do step 2. Creating a new branch now would break all of the existing PRs (as they target master) so it is easiest to work on master. At some point (probably mid-next week) I will create a v1.5.0rc1 tag along with a 1.5.x branch. We then go through (hopefully only one RC) and then when we are happy I create a new tag v1.5.0 and a 1.5.0-doc branch.
The mile stones are (realistically) a rough target, not a hard date.
For reference, #3707 is the current check list of what needs to be done to do a release, but @pelson has tooling to make it easier.
OceanWolf commented on Jul 20, 2015
Ahh, thanks, for me my main concern lies in pulling out the partial MEP22 code as we haven't stabilised it yet, not only with concern as to having had no testing on python3, as the recent bug shows, possible changes in API which @fariza wants to make (and I partially agree), and of course MEP27.
I also have concerns of pushing out recent merges that haven't had as much testing in python. I don't see why making a new branch now would break PRs... master remains unaffected so PRs will carry on as normal, we just backport urgent fixes from master to the 1.5 branch...
tacaswell commented on Jul 20, 2015
Because there are things in those PRs which are blockers for the release.
jenshnielsen commented on Jul 20, 2015
IMHO the problem is in the word "Just" For a project the size of Matplotlib. It is very easy to miss a PR which should have been back ported and backporting is actually a lot of work
OceanWolf commented on Jul 20, 2015
Okay... I didn't think it would take so much effort to backport. . I wouldn't have thought it seeing how nicely git works in general. I guess we can iron out any last minute problems during RC.
To make sure though, we will take out the new toolbar from 1.5 right? (see reasons above which I have mentioned in other PRs/issues), just that #4743 (comment) makes me nervous.
tacaswell commented on Aug 30, 2015
Closing this as it isn't really an issue.