You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@jreback : Besides, removing it from the Travis YAML, is it possible to also drop support for library versions that were needed to be compatible with Python 3.4 (e.g. numpy)? I imagine that the code that is "Python 3.4" compatible is actually just code compatible with older library versions.
@gfyoung not sure what you mean. numpy 1.7 is compat with 3.4 (in theory), so nothing really to drop here (except the actual version support / travis). I think code changes are minimal as well.
Is this already necessary? If it would not give much code clean-up, it is not much effort to keep compatibility a bit longer?
For 0.19.2, still 10% of all conda-forge downloads were for 3.4 packages (I know conda-forge stops with 3.4, but this percentage can be indicative for other downloads (main conda channel, pypi)).
conda-forge alone is not "the rest of the community" (and I suspect the main reason for dropping is that otherwise their build matrix becomes too large). I don't know of any other core packages already dropping support? Not that we can't be the first, but still wondering the necessity of this.
conda-forge dropping, so that means NO conda packages (not sure if defaults will have this for 3.4 or not, though I think it would have to be a request).
OUR build matrix is encumbered by this. So to be honest we could still support it w/o explicity testing it.
To be fair, breaking the 3.4 builds is not disastrous since they are allowed to fail. One other thing, have we given users any notice of dropping support for this version?
If we haven't, I would be inclined to agree with @jorisvandenbossche that we should wait. Perhaps we could warn in the next major release of the impending loss of support and then remove support for it in the next major version.
@gfyoung just want to clarify. just because something is allowed to fail, doesn't mean it actually is!
These builds are there because we want to exhaustively test things, but give quick feedback that for-the-most-part things work (hence the 5 main builds). And travis allows 5 concurrent builds so generally this fits well.
Yes, they can occasionally fail, but we do fix them!
If we eliminate the 3.4 builds then we won't know that they are failing. Though I will admit 3.4 is highly compat with 3.5 so I suspect that it would be unlikely for a 3.4 build to fail while a 3.5 one works (though possible).
Activity
[-]COMPAT: drop python 3.4[/-][+]DEPS: drop python 3.4[/+]gfyoung commentedon Jan 30, 2017
@jreback : Besides, removing it from the Travis YAML, is it possible to also drop support for library versions that were needed to be compatible with Python 3.4 (e.g.
numpy)? I imagine that the code that is "Python 3.4" compatible is actually just code compatible with older library versions.jreback commentedon Jan 30, 2017
@gfyoung not sure what you mean. numpy 1.7 is compat with 3.4 (in theory), so nothing really to drop here (except the actual version support / travis). I think code changes are minimal as well.
gfyoung commentedon Jan 30, 2017
I was referring to the fact that direct code "hacks" to be compatible with Python 3.4 are likely minimal as you said. Sounds good.
jorisvandenbossche commentedon Jan 30, 2017
Is this already necessary? If it would not give much code clean-up, it is not much effort to keep compatibility a bit longer?
For 0.19.2, still 10% of all conda-forge downloads were for 3.4 packages (I know conda-forge stops with 3.4, but this percentage can be indicative for other downloads (main conda channel, pypi)).
jreback commentedon Jan 30, 2017
well that's the point. As the rest of the community drops support, then we should as well.
jorisvandenbossche commentedon Jan 31, 2017
conda-forge alone is not "the rest of the community" (and I suspect the main reason for dropping is that otherwise their build matrix becomes too large). I don't know of any other core packages already dropping support? Not that we can't be the first, but still wondering the necessity of this.
jreback commentedon Jan 31, 2017
well the reason I put this on here is:
gfyoung commentedon Jan 31, 2017
To be fair, breaking the 3.4 builds is not disastrous since they are allowed to fail. One other thing, have we given users any notice of dropping support for this version?
If we haven't, I would be inclined to agree with @jorisvandenbossche that we should wait. Perhaps we could warn in the next major release of the impending loss of support and then remove support for it in the next major version.
jreback commentedon Jan 31, 2017
@gfyoung just want to clarify. just because something is
allowed to fail, doesn't mean it actually is!These builds are there because we want to exhaustively test things, but give quick feedback that for-the-most-part things work (hence the 5 main builds). And travis allows 5 concurrent builds so generally this fits well.
Yes, they can occasionally fail, but we do fix them!
If we eliminate the 3.4 builds then we won't know that they are failing. Though I will admit 3.4 is highly compat with 3.5 so I suspect that it would be unlikely for a 3.4 build to fail while a 3.5 one works (though possible).
31 remaining items