Scheduling the 1.7.1 and 1.8 releases
![](https://secure.gravatar.com/avatar/96dd777e397ab128fedab46af97a3a4a.jpg?s=120&d=mm&r=g)
Hi All, There are now some 14 non-merge commits in the 1.7.x branch including the critical diagonal leak fix. I think there is maybe one more critical backport and perhaps several low priority fixes, documentation and such, but I think we should start up the release process with a goal of getting 1.7.1 out by the middle of April. The development branch has been accumulating stuff since last summer, I suggest we look to get it out in May, branching at the end of this month. Thoughts? Chuck
![](https://secure.gravatar.com/avatar/97c543aca1ac7bbcfb5279d0300c8330.jpg?s=120&d=mm&r=g)
On Wed, Mar 6, 2013 at 6:43 PM, Charles R Harris <charlesr.harris@gmail.com> wrote:
What's the critical backport you're thinking of? This last shows just two backport PRs waiting to be merged, one trivial one that I just submitted, the other that needs a tweak but won't take long: https://github.com/numpy/numpy/issues?milestone=27&page=1&state=open But I agree, basically we should merge those two (today?) and then release the first RC as soon as Ondrej has a moment to do so...
The development branch has been accumulating stuff since last summer, I suggest we look to get it out in May, branching at the end of this month.
I would say "let's fix the blockers and then branch as soon as Ondrej has time to do it", but in practice I suspect this comes out the same as what you just said :-). I just pruned the list of blockers; here's what we've got: https://github.com/numpy/numpy/issues?milestone=1&page=1&state=open -n
![](https://secure.gravatar.com/avatar/5f88830d19f9c83e2ddfd913496c5025.jpg?s=120&d=mm&r=g)
On Wed, Mar 6, 2013 at 9:06 PM, Nathaniel Smith <njs@pobox.com> wrote:
I added issue 2999, which I think should be taken along. Other than that, +1 for a quick release.
It looks like we're not doing so well with setting Milestones correctly. Only 4 closed issues for 1.8.... Release quickly after 1.7.1 sounds good. Ralf
![](https://secure.gravatar.com/avatar/97c543aca1ac7bbcfb5279d0300c8330.jpg?s=120&d=mm&r=g)
On Fri, Mar 8, 2013 at 11:07 AM, Ondřej Čertík <ondrej.certik@gmail.com> wrote:
Big +1 to doing an RC from me. I guess conceptually this is like we just jumped back in time to right before we released 1.7.0, and merged a bunch more bug-fixes. We'd definitely have done another RC for the new changes then, so we should do one now too :-). -n
![](https://secure.gravatar.com/avatar/b4f6d4f8b501cb05fd054944a166a121.jpg?s=120&d=mm&r=g)
On Wed, 2013-03-06 at 11:43 -0700, Charles R Harris wrote:
Hi All,
<snip>
Hey, maybe it is a bit early, but I was wondering. What are the things that should be done before branching? Most of the blockers should be resolved? I think the largest of that are maybe the deprecations (but since 1.7.0 is not too long ago many of them maybe don't need touching). Aside from that, I think these are lurking/in-progress: Fix the piled up mapping.c things: * This means resolving https://github.com/numpy/numpy/pull/436 . It will be even worse now, but maybe at least most of it can be put in without too much work? * After that, non-integer deprecations should be done fully before 1.8. I think, but these need to change mapping.c too (the most work is probably the tests...): - https://github.com/numpy/numpy/pull/2891 - https://github.com/numpy/numpy/pull/2825 * (https://github.com/numpy/numpy/pull/2701) Are the 2to3 fixers supposed to be finished for 1.8? If yes there is probably no point in thinking about branching, etc. since back porting them all is just pain. Regards, Sebastian
![](https://secure.gravatar.com/avatar/97c543aca1ac7bbcfb5279d0300c8330.jpg?s=120&d=mm&r=g)
On Thu, Apr 11, 2013 at 11:32 AM, Sebastian Berg <sebastian@sipsolutions.net> wrote:
The "known blockers" list is here: https://github.com/numpy/numpy/issues?milestone=1&page=1&state=open #3194: this has a PR and will be closed shortly. #3008: this is fundamentally trivial, but annoying and confusing. I *think* we understand generally what we need to do here, just need re-arrange some header files so it works: https://github.com/numpy/numpy/issues/3008#issuecomment-14316385 #2905: trivial, needs doing #2830: all this actually needs is an INSTALL.txt update. #2801: need to rip NPY_CHAR out of master. trivial, needs doing. #596: needs bumping to 1.9, and a check whether the deprecation warning message explicitly says "1.8". if so then it should be made more vague. #456: same as #596 #378: need to merge #452. #294: same as #596
My feeling is that as a matter of policy, we should branch as soon as the blockers are fixed, and anything that isn't ready can go into 1.9. If you want a change into 1.8, you should hurry instead of making 1.8 (and everything else in it) wait ;-). -n
![](https://secure.gravatar.com/avatar/97c543aca1ac7bbcfb5279d0300c8330.jpg?s=120&d=mm&r=g)
On 11 Apr 2013 15:29, "Charles R Harris" <charlesr.harris@gmail.com> wrote:
On Thu, Apr 11, 2013 at 4:32 AM, Sebastian Berg <
sebastian@sipsolutions.net> wrote:
Will releasing 1.8 with these partially applied cause any issues that you can think of? (Like making later 1.8.1 backports easier or harder?) I guess we haven't noticed any problems backporting 1.7 changes yet, so hopefully it doesn't matter? -n
![](https://secure.gravatar.com/avatar/96dd777e397ab128fedab46af97a3a4a.jpg?s=120&d=mm&r=g)
On Thu, Apr 11, 2013 at 10:12 AM, Nathaniel Smith <njs@pobox.com> wrote:
I don't think they should cause problems unless they depend the presence of methods not present in 2.4 and 2.5, but that only affects 1.7. It is hard to say what things will cause problems in advance, but I suspect most things won't be difficult. If the ws_comma fixer is run and committed after 1.8 is released, there might be cherry-picking problems that would make backports a bit more work. There are also a couple of fixes yet to go in that involve version dependent imports, memoryview/buffer in particular, that would be a good to have in 1.8. Chuck
![](https://secure.gravatar.com/avatar/97c543aca1ac7bbcfb5279d0300c8330.jpg?s=120&d=mm&r=g)
On Wed, Mar 6, 2013 at 6:43 PM, Charles R Harris <charlesr.harris@gmail.com> wrote:
What's the critical backport you're thinking of? This last shows just two backport PRs waiting to be merged, one trivial one that I just submitted, the other that needs a tweak but won't take long: https://github.com/numpy/numpy/issues?milestone=27&page=1&state=open But I agree, basically we should merge those two (today?) and then release the first RC as soon as Ondrej has a moment to do so...
The development branch has been accumulating stuff since last summer, I suggest we look to get it out in May, branching at the end of this month.
I would say "let's fix the blockers and then branch as soon as Ondrej has time to do it", but in practice I suspect this comes out the same as what you just said :-). I just pruned the list of blockers; here's what we've got: https://github.com/numpy/numpy/issues?milestone=1&page=1&state=open -n
![](https://secure.gravatar.com/avatar/5f88830d19f9c83e2ddfd913496c5025.jpg?s=120&d=mm&r=g)
On Wed, Mar 6, 2013 at 9:06 PM, Nathaniel Smith <njs@pobox.com> wrote:
I added issue 2999, which I think should be taken along. Other than that, +1 for a quick release.
It looks like we're not doing so well with setting Milestones correctly. Only 4 closed issues for 1.8.... Release quickly after 1.7.1 sounds good. Ralf
![](https://secure.gravatar.com/avatar/97c543aca1ac7bbcfb5279d0300c8330.jpg?s=120&d=mm&r=g)
On Fri, Mar 8, 2013 at 11:07 AM, Ondřej Čertík <ondrej.certik@gmail.com> wrote:
Big +1 to doing an RC from me. I guess conceptually this is like we just jumped back in time to right before we released 1.7.0, and merged a bunch more bug-fixes. We'd definitely have done another RC for the new changes then, so we should do one now too :-). -n
![](https://secure.gravatar.com/avatar/b4f6d4f8b501cb05fd054944a166a121.jpg?s=120&d=mm&r=g)
On Wed, 2013-03-06 at 11:43 -0700, Charles R Harris wrote:
Hi All,
<snip>
Hey, maybe it is a bit early, but I was wondering. What are the things that should be done before branching? Most of the blockers should be resolved? I think the largest of that are maybe the deprecations (but since 1.7.0 is not too long ago many of them maybe don't need touching). Aside from that, I think these are lurking/in-progress: Fix the piled up mapping.c things: * This means resolving https://github.com/numpy/numpy/pull/436 . It will be even worse now, but maybe at least most of it can be put in without too much work? * After that, non-integer deprecations should be done fully before 1.8. I think, but these need to change mapping.c too (the most work is probably the tests...): - https://github.com/numpy/numpy/pull/2891 - https://github.com/numpy/numpy/pull/2825 * (https://github.com/numpy/numpy/pull/2701) Are the 2to3 fixers supposed to be finished for 1.8? If yes there is probably no point in thinking about branching, etc. since back porting them all is just pain. Regards, Sebastian
![](https://secure.gravatar.com/avatar/97c543aca1ac7bbcfb5279d0300c8330.jpg?s=120&d=mm&r=g)
On Thu, Apr 11, 2013 at 11:32 AM, Sebastian Berg <sebastian@sipsolutions.net> wrote:
The "known blockers" list is here: https://github.com/numpy/numpy/issues?milestone=1&page=1&state=open #3194: this has a PR and will be closed shortly. #3008: this is fundamentally trivial, but annoying and confusing. I *think* we understand generally what we need to do here, just need re-arrange some header files so it works: https://github.com/numpy/numpy/issues/3008#issuecomment-14316385 #2905: trivial, needs doing #2830: all this actually needs is an INSTALL.txt update. #2801: need to rip NPY_CHAR out of master. trivial, needs doing. #596: needs bumping to 1.9, and a check whether the deprecation warning message explicitly says "1.8". if so then it should be made more vague. #456: same as #596 #378: need to merge #452. #294: same as #596
My feeling is that as a matter of policy, we should branch as soon as the blockers are fixed, and anything that isn't ready can go into 1.9. If you want a change into 1.8, you should hurry instead of making 1.8 (and everything else in it) wait ;-). -n
![](https://secure.gravatar.com/avatar/97c543aca1ac7bbcfb5279d0300c8330.jpg?s=120&d=mm&r=g)
On 11 Apr 2013 15:29, "Charles R Harris" <charlesr.harris@gmail.com> wrote:
On Thu, Apr 11, 2013 at 4:32 AM, Sebastian Berg <
sebastian@sipsolutions.net> wrote:
Will releasing 1.8 with these partially applied cause any issues that you can think of? (Like making later 1.8.1 backports easier or harder?) I guess we haven't noticed any problems backporting 1.7 changes yet, so hopefully it doesn't matter? -n
![](https://secure.gravatar.com/avatar/96dd777e397ab128fedab46af97a3a4a.jpg?s=120&d=mm&r=g)
On Thu, Apr 11, 2013 at 10:12 AM, Nathaniel Smith <njs@pobox.com> wrote:
I don't think they should cause problems unless they depend the presence of methods not present in 2.4 and 2.5, but that only affects 1.7. It is hard to say what things will cause problems in advance, but I suspect most things won't be difficult. If the ws_comma fixer is run and committed after 1.8 is released, there might be cherry-picking problems that would make backports a bit more work. There are also a couple of fixes yet to go in that involve version dependent imports, memoryview/buffer in particular, that would be a good to have in 1.8. Chuck
participants (5)
-
Charles R Harris
-
Nathaniel Smith
-
Ondřej Čertík
-
Ralf Gommers
-
Sebastian Berg