Re: [Numpy-discussion] 1.8 release update
On Fri, May 31, 2013 at 11:47 PM, Charles R Harris charlesr.har...@gmail.com wrote: Hi All, Most of the PR's that were mentioned as desirable for the 1.8 release have been merged, or look to be merged in the next week or two. The current list of blockershttps://github.com/numpy/numpy/issues?milestone=1page=1state=opendoesn't look to severe to me but I suspect that it is incomplete. Indeed nothing serious there. I added a ticket for the timezone issue, https://github.com/numpy/numpy/issues/3388. The major outstanding issue I see is datetime and I'd like to get a small group together to work that out. As a start I think such a group should include Christopher Barker and Wes McKinney. Suggestions for other folks, or even volunteers, to be part of such a group are welcome. A lot of stuff has piled up over the last year for inclusion in the 1.8 release, and I'm sure some bugs and regressions have crept in along with the new code. On that account a lengthy wringing out period is probably going to be needed, so the sooner we can get the 1.8 branch tagged the better. I'd like to shoot for getting that done in 2-3 weeks. How does that match with getting the datetime situation sorted out? I don't think we're in a hurry with branching before we at least have an idea about what to do about datetime. Other than that, soonish sounds good to me. We should make an attempt to merge PRs that have been open for a while though. Ralf If there look to be difficult issues remaining, perhaps they can be worked out at scipy2013 if there is enough interest. Thoughts? Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] 1.8 release
On Thu, Apr 25, 2013 at 8:19 AM, Dave Hirschfeld dave.hirschf...@gmail.comwrote: Hi All,I think it is time to start the runup to the 1.8 release. I don't know of any outstanding blockers but if anyone has a PR/issue that they feel needs to be in the next Numpy release now is the time to make it known.Chuck It would be good to get the utc-everywhere fix for datetime64 in there if someone has time to look into it. +1 I've been on vacation, so haven't written up the various notes and comments as a NEP yet -- I'll try to do that soon. There are some larger proposals in the mix, which I doubt could be done by 1.8, but we really should fix the utc-everywhere issue ASAP. I think it will be pretty easy to do, but someone still needs to do it... -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/ORR(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception chris.bar...@noaa.gov ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] 1.8 release
On Thu, Apr 25, 2013 at 11:16 AM, Charles R Harris charlesr.har...@gmail.com wrote: Hi All, I think it is time to start the runup to the 1.8 release. I don't know of any outstanding blockers but if anyone has a PR/issue that they feel needs to be in the next Numpy release now is the time to make it known. Chuck Has a np.minmax() function been added yet? I know it keeps getting +1's whenever suggested, but I haven't seen it done yet. Another annoyance is the lack of a np.nanmean() and np.nanstd() function. Ben Root ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] 1.8 release
On Mon, Apr 29, 2013 at 1:04 PM, Benjamin Root ben.r...@ou.edu wrote: On Thu, Apr 25, 2013 at 11:16 AM, Charles R Harris charlesr.har...@gmail.com wrote: Hi All, I think it is time to start the runup to the 1.8 release. I don't know of any outstanding blockers but if anyone has a PR/issue that they feel needs to be in the next Numpy release now is the time to make it known. Chuck Has a np.minmax() function been added yet? I know it keeps getting +1's whenever suggested, but I haven't seen it done yet. Another annoyance is the lack of a np.nanmean() and np.nanstd() function. Best make this a separate thread and open issues based on the outcome. Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] 1.8 release
On Mon, Apr 29, 2013 at 12:07 PM, Charles R Harris charlesr.har...@gmail.com wrote: It would be good to get the utc-everywhere fix for datetime64 in there if someone has time to look into it. +1 I've been on vacation, so haven't written up the various notes and comments as a NEP yet -- I'll try to do that soon. There are some larger proposals in the mix, which I doubt could be done by 1.8, but we really should fix the utc-everywhere issue ASAP. I think it will be pretty easy to do, but someone still needs to do it... Is there a issue for this? no -- I don't think so -- just a bunch of discussion on the list. I was starting down the path of a proper NEP, etc, but I think that: a) Datetime64 is still officially experimental, so we can change things more rapidly than we might otherwise. b) It's really pretty broken as it is. I'll see if I can open an issue for the easy fix. -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/ORR(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception chris.bar...@noaa.gov ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] 1.8 release
On Mon, Apr 29, 2013 at 12:12 PM, Chris Barker - NOAA Federal chris.bar...@noaa.gov wrote: It would be good to get the utc-everywhere fix for datetime64 in there if someone has time to look into it. I'll see if I can open an issue for the easy fix. DONE: Issue #3290 -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/ORR(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception chris.bar...@noaa.gov ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] 1.8 release
Charles R Harris charlesr.harris at gmail.com writes: Hi All,I think it is time to start the runup to the 1.8 release. I don't know of any outstanding blockers but if anyone has a PR/issue that they feel needs to be in the next Numpy release now is the time to make it known.Chuck It would be good to get the utc-everywhere fix for datetime64 in there if someone has time to look into it. Thanks, Dave ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] 1.8 release
On Thu, 2013-04-25 at 09:16 -0600, Charles R Harris wrote: Hi All, I think it is time to start the runup to the 1.8 release. I don't know of any outstanding blockers but if anyone has a PR/issue that they feel needs to be in the next Numpy release now is the time to make it known. Sounds good, I would like to get the deprecation stuff done, because if we prefer to do it deeper down (I do), it changes the warnings a little and what happens when they are raised as errors. - Sebastian Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] 1.8 release
I would love to get the following pull requests of mine merged in: https://github.com/numpy/numpy/pull/2822 https://github.com/numpy/numpy/pull/462 https://github.com/numpy/numpy/pull/359 https://github.com/numpy/numpy/pull/2821 The last one probably requires a bit more work, but I'm still waiting on feedback on my solution (see my last comment in the PR discussion thread). Thanks, -Jay On Thu, Apr 25, 2013 at 10:16 AM, Charles R Harris charlesr.har...@gmail.com wrote: Hi All, I think it is time to start the runup to the 1.8 release. I don't know of any outstanding blockers but if anyone has a PR/issue that they feel needs to be in the next Numpy release now is the time to make it known. Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] 1.8 release
Hi, On Mon, Jan 14, 2013 at 12:19 AM, David Cournapeau courn...@gmail.com wrote: On Sun, Jan 13, 2013 at 5:26 PM, Nathaniel Smith n...@pobox.com wrote: On Sun, Jan 13, 2013 at 7:03 PM, Charles R Harris charlesr.har...@gmail.com wrote: Now that 1.7 is nearing release, it's time to look forward to the 1.8 release. I'd like us to get back to the twice yearly schedule that we tried to maintain through the 1.3 - 1.6 releases, so I propose a June release as a goal. Call it the Spring Cleaning release. As to content, I'd like to see the following. Removal of Python 2.4-2.5 support. Removal of SCons support. The index work consolidated. Initial stab at removing the need for 2to3. See Pauli's PR for scipy. Miscellaneous enhancements and fixes. I'd actually like to propose a faster release cycle than this, even. Perhaps 3 months between releases; 2 months from release n to the first beta of n+1? The consequences would be: * Changes get out to users faster. * Each release is smaller, so it's easier for downstream projects to adjust to each release -- instead of having this giant pile of changes to work through all at once every 6-12 months * End-users are less scared of updating, because the changes aren't so overwhelming, so they end up actually testing (and getting to take advantage of) the new stuff more. * We get feedback more quickly, so we can fix up whatever we break while we still know what we did. * And for larger changes, if we release them incrementally, we can get feedback before we've gone miles down the wrong path. * Releases come out on time more often -- sort of paradoxical, but with small, frequent releases, beta cycles go smoother, and it's easier to say don't worry, I'll get it ready for next time, or right, that patch was less done than we thought, let's take it out for now (also this is much easier if we don't have another years worth of changes committed on top of the patch!). * If your schedule does slip, then you still end up with a 6 month release cycle. 1.6.x was branched from master in March 2011 and released in May 2011. 1.7.x was branched from master in July 2012 and still isn't out. But at least we've finally found and fixed the second to last bug! Wouldn't it be nice to have a 2-4 week beta cycle that only found trivial and expected problems? We *already* have 6 months worth of feature work in master that won't be in the *next* release. Note 1: if we do do this, then we'll also want to rethink the deprecation cycle a bit -- right now we've sort of vaguely been saying well, we'll deprecate it in release n and take it out in n+1. Whenever that is. 3 months definitely isn't long enough for a deprecation period, so if we do do this then we'll want to deprecate things for multiple releases before actually removing them. Details to be determined. Note 2: in this kind of release schedule, you definitely don't want to say here are the features that will be in the next release!, because then you end up slipping and sliding all over the place. Instead you say here are some things that I want to work on next, and we'll see which release they end up in. Since we're already following the rule that nothing goes into master until it's done and tested and ready for release anyway, this doesn't really change much. Thoughts? Hey, my time to have a time-machine: http://mail.scipy.org/pipermail/numpy-discussion/2008-May/033754.html I still think it is a good idea :) I guess it is the release manager who has by far the largest say in this. Who will that be for the next year or so? Best, Matthew ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] 1.8 release
Hi, I don't volontear for the next release manager, but +1 for shorter releases. I heard just good comments from that. Also, I'm not sure it would ask more from the release manager. Do someone have an idea? The most work I do as a release manager for theano is the preparation/tests/release notes and this depend on the amont of new stuff. And this seam exponential on the number of new changes in the release, not linear (no data, just an impression...). Making smaller release make this easier. But yes, this mean more announces. But this isn't what take the most times. Also, doing the release notes more frequently mean it is more recent in memory when you check the PR merged, so it make it easier to do. But what prevent us from making shorter release? Oother priorities that can't wait, like work for papers to submit, or for collaboration with partners. just my 2cents. Fred On Mon, Jan 14, 2013 at 7:18 AM, Matthew Brett matthew.br...@gmail.com wrote: Hi, On Mon, Jan 14, 2013 at 12:19 AM, David Cournapeau courn...@gmail.com wrote: On Sun, Jan 13, 2013 at 5:26 PM, Nathaniel Smith n...@pobox.com wrote: On Sun, Jan 13, 2013 at 7:03 PM, Charles R Harris charlesr.har...@gmail.com wrote: Now that 1.7 is nearing release, it's time to look forward to the 1.8 release. I'd like us to get back to the twice yearly schedule that we tried to maintain through the 1.3 - 1.6 releases, so I propose a June release as a goal. Call it the Spring Cleaning release. As to content, I'd like to see the following. Removal of Python 2.4-2.5 support. Removal of SCons support. The index work consolidated. Initial stab at removing the need for 2to3. See Pauli's PR for scipy. Miscellaneous enhancements and fixes. I'd actually like to propose a faster release cycle than this, even. Perhaps 3 months between releases; 2 months from release n to the first beta of n+1? The consequences would be: * Changes get out to users faster. * Each release is smaller, so it's easier for downstream projects to adjust to each release -- instead of having this giant pile of changes to work through all at once every 6-12 months * End-users are less scared of updating, because the changes aren't so overwhelming, so they end up actually testing (and getting to take advantage of) the new stuff more. * We get feedback more quickly, so we can fix up whatever we break while we still know what we did. * And for larger changes, if we release them incrementally, we can get feedback before we've gone miles down the wrong path. * Releases come out on time more often -- sort of paradoxical, but with small, frequent releases, beta cycles go smoother, and it's easier to say don't worry, I'll get it ready for next time, or right, that patch was less done than we thought, let's take it out for now (also this is much easier if we don't have another years worth of changes committed on top of the patch!). * If your schedule does slip, then you still end up with a 6 month release cycle. 1.6.x was branched from master in March 2011 and released in May 2011. 1.7.x was branched from master in July 2012 and still isn't out. But at least we've finally found and fixed the second to last bug! Wouldn't it be nice to have a 2-4 week beta cycle that only found trivial and expected problems? We *already* have 6 months worth of feature work in master that won't be in the *next* release. Note 1: if we do do this, then we'll also want to rethink the deprecation cycle a bit -- right now we've sort of vaguely been saying well, we'll deprecate it in release n and take it out in n+1. Whenever that is. 3 months definitely isn't long enough for a deprecation period, so if we do do this then we'll want to deprecate things for multiple releases before actually removing them. Details to be determined. Note 2: in this kind of release schedule, you definitely don't want to say here are the features that will be in the next release!, because then you end up slipping and sliding all over the place. Instead you say here are some things that I want to work on next, and we'll see which release they end up in. Since we're already following the rule that nothing goes into master until it's done and tested and ready for release anyway, this doesn't really change much. Thoughts? Hey, my time to have a time-machine: http://mail.scipy.org/pipermail/numpy-discussion/2008-May/033754.html I still think it is a good idea :) I guess it is the release manager who has by far the largest say in this. Who will that be for the next year or so? Best, Matthew ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] 1.8 release
On Mon, Jan 14, 2013 at 1:19 AM, David Cournapeau courn...@gmail.comwrote: On Sun, Jan 13, 2013 at 5:26 PM, Nathaniel Smith n...@pobox.com wrote: On Sun, Jan 13, 2013 at 7:03 PM, Charles R Harris charlesr.har...@gmail.com wrote: Now that 1.7 is nearing release, it's time to look forward to the 1.8 release. I'd like us to get back to the twice yearly schedule that we tried to maintain through the 1.3 - 1.6 releases, so I propose a June release as a goal. Call it the Spring Cleaning release. As to content, I'd like to see the following. Removal of Python 2.4-2.5 support. Removal of SCons support. The index work consolidated. Initial stab at removing the need for 2to3. See Pauli's PR for scipy. Miscellaneous enhancements and fixes. I'd actually like to propose a faster release cycle than this, even. Perhaps 3 months between releases; 2 months from release n to the first beta of n+1? The consequences would be: * Changes get out to users faster. * Each release is smaller, so it's easier for downstream projects to adjust to each release -- instead of having this giant pile of changes to work through all at once every 6-12 months * End-users are less scared of updating, because the changes aren't so overwhelming, so they end up actually testing (and getting to take advantage of) the new stuff more. * We get feedback more quickly, so we can fix up whatever we break while we still know what we did. * And for larger changes, if we release them incrementally, we can get feedback before we've gone miles down the wrong path. * Releases come out on time more often -- sort of paradoxical, but with small, frequent releases, beta cycles go smoother, and it's easier to say don't worry, I'll get it ready for next time, or right, that patch was less done than we thought, let's take it out for now (also this is much easier if we don't have another years worth of changes committed on top of the patch!). * If your schedule does slip, then you still end up with a 6 month release cycle. 1.6.x was branched from master in March 2011 and released in May 2011. 1.7.x was branched from master in July 2012 and still isn't out. But at least we've finally found and fixed the second to last bug! Wouldn't it be nice to have a 2-4 week beta cycle that only found trivial and expected problems? We *already* have 6 months worth of feature work in master that won't be in the *next* release. Note 1: if we do do this, then we'll also want to rethink the deprecation cycle a bit -- right now we've sort of vaguely been saying well, we'll deprecate it in release n and take it out in n+1. Whenever that is. 3 months definitely isn't long enough for a deprecation period, so if we do do this then we'll want to deprecate things for multiple releases before actually removing them. Details to be determined. Note 2: in this kind of release schedule, you definitely don't want to say here are the features that will be in the next release!, because then you end up slipping and sliding all over the place. Instead you say here are some things that I want to work on next, and we'll see which release they end up in. Since we're already following the rule that nothing goes into master until it's done and tested and ready for release anyway, this doesn't really change much. Thoughts? Hey, my time to have a time-machine: http://mail.scipy.org/pipermail/numpy-discussion/2008-May/033754.html I still think it is a good idea :) +1 for faster and time-based releases. 3 months does sound a little too short to me (5 or 6 would be better), since a release cycle typically doesn't fit in one month. Ralf ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] 1.8 release
On Mon, Jan 14, 2013 at 4:45 PM, Frédéric Bastien no...@nouiz.org wrote: I don't volontear for the next release manager, but +1 for shorter releases. I heard just good comments from that. Also, I'm not sure it would ask more from the release manager. Do someone have an idea? The most work I do as a release manager for theano is the preparation/tests/release notes and this depend on the amont of new stuff. And this seam exponential on the number of new changes in the release, not linear (no data, just an impression...). Making smaller release make this easier. But yes, this mean more announces. But this isn't what take the most times. Also, doing the release notes more frequently mean it is more recent in memory when you check the PR merged, so it make it easier to do. Right, this is my experience too -- that it's actually easier to put out more releases, because each one is manageable and you get a routine going. (Oops, it's March, better find an hour this week to check the release notes and run the 'release beta1' script.) It becomes almost boring, which is awesome. Putting out 5 small releases is much, MUCH easier than putting out one giant 5x bigger release. On Mon, Jan 14, 2013 at 9:26 PM, Ralf Gommers ralf.gomm...@gmail.com wrote: +1 for faster and time-based releases. 3 months does sound a little too short to me (5 or 6 would be better), since a release cycle typically doesn't fit in one month. The release cycle for 6-12+ months of changes doesn't typically fit in one month, but we've never tried for a smaller release, so who knows. I suppose that theoretically, as scientists, what we ought to do is to attempt 1-2 releases at as aggressive a pace as we can imagine to see how it goes, and then we'll have the data to interpolate the correct speed instead of extrapolating... ;-) On Mon, Jan 14, 2013 at 12:14 AM, Charles R Harris charlesr.har...@gmail.com wrote: I think three months is a bit short. Much will depend on the release manager and I not sure what Andrej's plans are. I'd happily nominate you for that role ;) Careful, or I'll nominate you back! ;-) Seriously, though, Ondrej is doing a great job, I doubt I'd do as well... Ondrej: I know you're still doing heroic work getting 1.7 pulled together, but if you have a moment-- Are you planning to stick around as release manager after 1.7? And if so, what are your thoughts on attempting such a short cycle? -n ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] 1.8 release
On Sun, Jan 13, 2013 at 7:03 PM, Charles R Harris charlesr.har...@gmail.com wrote: Now that 1.7 is nearing release, it's time to look forward to the 1.8 release. I'd like us to get back to the twice yearly schedule that we tried to maintain through the 1.3 - 1.6 releases, so I propose a June release as a goal. Call it the Spring Cleaning release. As to content, I'd like to see the following. Removal of Python 2.4-2.5 support. Removal of SCons support. The index work consolidated. Initial stab at removing the need for 2to3. See Pauli's PR for scipy. Miscellaneous enhancements and fixes. I'd actually like to propose a faster release cycle than this, even. Perhaps 3 months between releases; 2 months from release n to the first beta of n+1? The consequences would be: * Changes get out to users faster. * Each release is smaller, so it's easier for downstream projects to adjust to each release -- instead of having this giant pile of changes to work through all at once every 6-12 months * End-users are less scared of updating, because the changes aren't so overwhelming, so they end up actually testing (and getting to take advantage of) the new stuff more. * We get feedback more quickly, so we can fix up whatever we break while we still know what we did. * And for larger changes, if we release them incrementally, we can get feedback before we've gone miles down the wrong path. * Releases come out on time more often -- sort of paradoxical, but with small, frequent releases, beta cycles go smoother, and it's easier to say don't worry, I'll get it ready for next time, or right, that patch was less done than we thought, let's take it out for now (also this is much easier if we don't have another years worth of changes committed on top of the patch!). * If your schedule does slip, then you still end up with a 6 month release cycle. 1.6.x was branched from master in March 2011 and released in May 2011. 1.7.x was branched from master in July 2012 and still isn't out. But at least we've finally found and fixed the second to last bug! Wouldn't it be nice to have a 2-4 week beta cycle that only found trivial and expected problems? We *already* have 6 months worth of feature work in master that won't be in the *next* release. Note 1: if we do do this, then we'll also want to rethink the deprecation cycle a bit -- right now we've sort of vaguely been saying well, we'll deprecate it in release n and take it out in n+1. Whenever that is. 3 months definitely isn't long enough for a deprecation period, so if we do do this then we'll want to deprecate things for multiple releases before actually removing them. Details to be determined. Note 2: in this kind of release schedule, you definitely don't want to say here are the features that will be in the next release!, because then you end up slipping and sliding all over the place. Instead you say here are some things that I want to work on next, and we'll see which release they end up in. Since we're already following the rule that nothing goes into master until it's done and tested and ready for release anyway, this doesn't really change much. Thoughts? -n ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] 1.8 release
On Sun, Jan 13, 2013 at 4:26 PM, Nathaniel Smith n...@pobox.com wrote: On Sun, Jan 13, 2013 at 7:03 PM, Charles R Harris charlesr.har...@gmail.com wrote: Now that 1.7 is nearing release, it's time to look forward to the 1.8 release. I'd like us to get back to the twice yearly schedule that we tried to maintain through the 1.3 - 1.6 releases, so I propose a June release as a goal. Call it the Spring Cleaning release. As to content, I'd like to see the following. Removal of Python 2.4-2.5 support. Removal of SCons support. The index work consolidated. Initial stab at removing the need for 2to3. See Pauli's PR for scipy. Miscellaneous enhancements and fixes. I'd actually like to propose a faster release cycle than this, even. Perhaps 3 months between releases; 2 months from release n to the first beta of n+1? The consequences would be: * Changes get out to users faster. * Each release is smaller, so it's easier for downstream projects to adjust to each release -- instead of having this giant pile of changes to work through all at once every 6-12 months * End-users are less scared of updating, because the changes aren't so overwhelming, so they end up actually testing (and getting to take advantage of) the new stuff more. * We get feedback more quickly, so we can fix up whatever we break while we still know what we did. * And for larger changes, if we release them incrementally, we can get feedback before we've gone miles down the wrong path. * Releases come out on time more often -- sort of paradoxical, but with small, frequent releases, beta cycles go smoother, and it's easier to say don't worry, I'll get it ready for next time, or right, that patch was less done than we thought, let's take it out for now (also this is much easier if we don't have another years worth of changes committed on top of the patch!). * If your schedule does slip, then you still end up with a 6 month release cycle. 1.6.x was branched from master in March 2011 and released in May 2011. 1.7.x was branched from master in July 2012 and still isn't out. But at least we've finally found and fixed the second to last bug! Actually, the first branch was late Dec 2011, IIRC, maybe Feb 2012. We've had about a year delay and I'm not convinced it was worth it. Wouldn't it be nice to have a 2-4 week beta cycle that only found trivial and expected problems? We *already* have 6 months worth of feature work in master that won't be in the *next* release. Note 1: if we do do this, then we'll also want to rethink the deprecation cycle a bit -- right now we've sort of vaguely been saying well, we'll deprecate it in release n and take it out in n+1. Whenever that is. 3 months definitely isn't long enough for a deprecation period, so if we do do this then we'll want to deprecate things for multiple releases before actually removing them. Details to be determined. Deprecations should probably be time based. Note 2: in this kind of release schedule, you definitely don't want to say here are the features that will be in the next release!, because then you end up slipping and sliding all over the place. Instead you say here are some things that I want to work on next, and we'll see which release they end up in. Since we're already following the rule that nothing goes into master until it's done and tested and ready for release anyway, this doesn't really change much. Thoughts? I think three months is a bit short. Much will depend on the release manager and I not sure what Andrej's plans are. I'd happily nominate you for that role ;) Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] 1.8 release
On Sun, Jan 13, 2013 at 5:26 PM, Nathaniel Smith n...@pobox.com wrote: On Sun, Jan 13, 2013 at 7:03 PM, Charles R Harris charlesr.har...@gmail.com wrote: Now that 1.7 is nearing release, it's time to look forward to the 1.8 release. I'd like us to get back to the twice yearly schedule that we tried to maintain through the 1.3 - 1.6 releases, so I propose a June release as a goal. Call it the Spring Cleaning release. As to content, I'd like to see the following. Removal of Python 2.4-2.5 support. Removal of SCons support. The index work consolidated. Initial stab at removing the need for 2to3. See Pauli's PR for scipy. Miscellaneous enhancements and fixes. I'd actually like to propose a faster release cycle than this, even. Perhaps 3 months between releases; 2 months from release n to the first beta of n+1? The consequences would be: * Changes get out to users faster. * Each release is smaller, so it's easier for downstream projects to adjust to each release -- instead of having this giant pile of changes to work through all at once every 6-12 months * End-users are less scared of updating, because the changes aren't so overwhelming, so they end up actually testing (and getting to take advantage of) the new stuff more. * We get feedback more quickly, so we can fix up whatever we break while we still know what we did. * And for larger changes, if we release them incrementally, we can get feedback before we've gone miles down the wrong path. * Releases come out on time more often -- sort of paradoxical, but with small, frequent releases, beta cycles go smoother, and it's easier to say don't worry, I'll get it ready for next time, or right, that patch was less done than we thought, let's take it out for now (also this is much easier if we don't have another years worth of changes committed on top of the patch!). * If your schedule does slip, then you still end up with a 6 month release cycle. 1.6.x was branched from master in March 2011 and released in May 2011. 1.7.x was branched from master in July 2012 and still isn't out. But at least we've finally found and fixed the second to last bug! Wouldn't it be nice to have a 2-4 week beta cycle that only found trivial and expected problems? We *already* have 6 months worth of feature work in master that won't be in the *next* release. Note 1: if we do do this, then we'll also want to rethink the deprecation cycle a bit -- right now we've sort of vaguely been saying well, we'll deprecate it in release n and take it out in n+1. Whenever that is. 3 months definitely isn't long enough for a deprecation period, so if we do do this then we'll want to deprecate things for multiple releases before actually removing them. Details to be determined. Note 2: in this kind of release schedule, you definitely don't want to say here are the features that will be in the next release!, because then you end up slipping and sliding all over the place. Instead you say here are some things that I want to work on next, and we'll see which release they end up in. Since we're already following the rule that nothing goes into master until it's done and tested and ready for release anyway, this doesn't really change much. Thoughts? Hey, my time to have a time-machine: http://mail.scipy.org/pipermail/numpy-discussion/2008-May/033754.html I still think it is a good idea :) cheers, David ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
