Starting conversation about Py2 deprecation
Hi folks,
On the call yesterday, the topic of dropping support for Py2 came up. This site provides some context:
http://www.python3statement.org/
At present, we're planning to have a 3.4 release sometime in the early summer, and then aiming for a yt 4.0 sometime about six months later. yt 4.0 will have the demeshening.
A proposal was floated to have yt 4.0 be the last release that explicitly supports python 2, and then to "softly" drop support for python 2 during the cycle for yt 4.1, which would be about six months later, we anticipate. This would mean not testing on py2 anymore and potentially removing some of the shims and six calls to dual-support.
Some more discussion is in the meeting notes:
https://github.com/yt-project/meeting-notes/blob/master/notes-20170419.md
I don't know if this is something we should actively discuss yet, but I wanted to put it out there. I personally support this proposal.
-Matt
my thought on this is that removing python 2 support should occur on a major release, not a point release. It seems odd that yt 4.0 supports both 2 and 3, but 4.1 drops python 2 support. Might be confusing for users.
On Thu, Apr 20, 2017 at 4:27 PM, Matthew Turk matthewturk@gmail.com wrote:
Hi folks,
On the call yesterday, the topic of dropping support for Py2 came up. This site provides some context:
http://www.python3statement.org/
At present, we're planning to have a 3.4 release sometime in the early summer, and then aiming for a yt 4.0 sometime about six months later. yt 4.0 will have the demeshening.
A proposal was floated to have yt 4.0 be the last release that explicitly supports python 2, and then to "softly" drop support for python 2 during the cycle for yt 4.1, which would be about six months later, we anticipate. This would mean not testing on py2 anymore and potentially removing some of the shims and six calls to dual-support.
Some more discussion is in the meeting notes:
https://github.com/yt-project/meeting-notes/blob/master/notes-20170419.md
I don't know if this is something we should actively discuss yet, but I wanted to put it out there. I personally support this proposal.
-Matt
yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
We had a conversation about this point yesterday, in fact I was the one that brought this point up.
Though in my mind I agree with you at first that it makes more sense to do this at 4.0, there are two reasons why we should wait until 4.1:
1. gives users more time to prepare 2. gives python 2 people a chance to use the new features (especially demeshening) at least for one 4.x version
On Apr 20, 2017, at 5:27 PM, Michael Zingale michael.zingale@stonybrook.edu wrote:
my thought on this is that removing python 2 support should occur on a major release, not a point release. It seems odd that yt 4.0 supports both 2 and 3, but 4.1 drops python 2 support. Might be confusing for users.
On Thu, Apr 20, 2017 at 4:27 PM, Matthew Turk <matthewturk@gmail.com mailto:matthewturk@gmail.com> wrote: Hi folks,
On the call yesterday, the topic of dropping support for Py2 came up. This site provides some context:
http://www.python3statement.org/ http://www.python3statement.org/
At present, we're planning to have a 3.4 release sometime in the early summer, and then aiming for a yt 4.0 sometime about six months later. yt 4.0 will have the demeshening.
A proposal was floated to have yt 4.0 be the last release that explicitly supports python 2, and then to "softly" drop support for python 2 during the cycle for yt 4.1, which would be about six months later, we anticipate. This would mean not testing on py2 anymore and potentially removing some of the shims and six calls to dual-support.
Some more discussion is in the meeting notes:
https://github.com/yt-project/meeting-notes/blob/master/notes-20170419.md https://github.com/yt-project/meeting-notes/blob/master/notes-20170419.md
I don't know if this is something we should actively discuss yet, but I wanted to put it out there. I personally support this proposal.
-Matt
yt-dev mailing list yt-dev@lists.spacepope.org mailto:yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
-- Michael Zingale Associate Professor
Dept. of Physics & Astronomy • Stony Brook University • Stony Brook, NY 11794-3800 phone: 631-632-8225 e-mail: Michael.Zingale@stonybrook.edu mailto:Michael.Zingale@stonybrook.edu web: http://www.astro.sunysb.edu/mzingale http://www.astro.sunysb.edu/mzingale github: http://github.com/zingale http://github.com/zingale
yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
I guess it doesn't matter much whether we call it 4.1 or 5.0. We could commit ahead of time that the only major breaking change in 5.0 would be dropping python2 support.
On Thu, Apr 20, 2017 at 4:29 PM, John Zuhone jzuhone@gmail.com wrote:
We had a conversation about this point yesterday, in fact I was the one that brought this point up.
Though in my mind I agree with you at first that it makes more sense to do this at 4.0, there are two reasons why we should wait until 4.1:
- gives users more time to prepare
- gives python 2 people a chance to use the new features (especially
demeshening) at least for one 4.x version
On Apr 20, 2017, at 5:27 PM, Michael Zingale <michael.zingale@stonybrook. edu> wrote:
my thought on this is that removing python 2 support should occur on a major release, not a point release. It seems odd that yt 4.0 supports both 2 and 3, but 4.1 drops python 2 support. Might be confusing for users.
On Thu, Apr 20, 2017 at 4:27 PM, Matthew Turk matthewturk@gmail.com wrote:
Hi folks,
On the call yesterday, the topic of dropping support for Py2 came up. This site provides some context:
http://www.python3statement.org/
At present, we're planning to have a 3.4 release sometime in the early summer, and then aiming for a yt 4.0 sometime about six months later. yt 4.0 will have the demeshening.
A proposal was floated to have yt 4.0 be the last release that explicitly supports python 2, and then to "softly" drop support for python 2 during the cycle for yt 4.1, which would be about six months later, we anticipate. This would mean not testing on py2 anymore and potentially removing some of the shims and six calls to dual-support.
Some more discussion is in the meeting notes:
https://github.com/yt-project/meeting-notes/blob/master/notes-20170419.md
I don't know if this is something we should actively discuss yet, but I wanted to put it out there. I personally support this proposal.
-Matt
yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
-- Michael Zingale Associate Professor
Dept. of Physics & Astronomy • Stony Brook University • Stony Brook, NY 11794-3800 *phone*: 631-632-8225 <(631)%20632-8225> *e-mail*: Michael.Zingale@stonybrook.edu *web*: http://www.astro.sunysb.edu/mzingale github: http://github.com/zingale
yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
If we do drop Python2 support, I'd prefer to do it fully and not intentionally leave in six and all of the code that's conditional on Python version. Leaving in the shim code makes the codebase harder to understand, so we should take the opportunity to remove it once we have the chance to make it more approachable and maintainable. In addition, I don't feel comfortable letting people install yt on a version of python that we're intentionally not testing. There should just eventually be a yt version that isn't installable on python2. We will of course need to communicate with out community about that, and announce the transition well ahead of time. Thankfully we are in good company on these announcements, and many other packages (notably IPython) have begun to make their own transitions to python3-only codebases.
Up until now we've tried to avoid having too many breaking changes, and it just so happens that we're thinking about how to handle two of them. The first is the stuff that we want to go into yt 4.0 (non-spatial domains and the demeshening) and the second is dropping Python3. I guess we're most efficient in spending breaking change chits with our userbase if we group these two changes together. Ideally we'd do that, but several people on the call yesterday objected to that but at the same time seemed amenable to the compromise that we drop python3 support soon after releasing a version of yt that includes the demeshening and non-spatial domains. So that means dropping python3 support needs to happen after yt 4.0.
I think Matt would prefer not to to a yt 5.0 release soon after yt 4.0. However, as Mike points out, dropping python3 support is a breaking change for some people, so we probably need to indicate that in the version number. Taken together, I think that means we need to do both a yt 4.0 and yt 5.0 release.
So that means we need to decide now how long we want the delay between releasing yt 4.0 and dropping python3 support in yt 5.0 is going to be. Are we going to release yt 4.1 with new features but still supporting python2? Or are we going to move straight to yt 5.0, possibly supporting yt 4.0 with bugfixes for an extended period. Our messaging here I think depends on what the timeline should be.
If we want to drop python2 support in 2018, I think there should be a yt 4.1. If we want to drop it in 2019 or 2020, then we have plenty of time to accumulate other ideas for breaking changes that we want to include in yt 5.0 and we might end up doing yt 4.1 and 4.2 releases.
Personally, I'm leaning towards dropping Python2 support sooner, in 2018. Would anyone prefer a later switch?
On Thu, Apr 20, 2017 at 4:31 PM, Nathan Goldbaum nathan12343@gmail.com wrote:
I guess it doesn't matter much whether we call it 4.1 or 5.0. We could commit ahead of time that the only major breaking change in 5.0 would be dropping python2 support.
On Thu, Apr 20, 2017 at 4:29 PM, John Zuhone jzuhone@gmail.com wrote:
We had a conversation about this point yesterday, in fact I was the one that brought this point up.
Though in my mind I agree with you at first that it makes more sense to do this at 4.0, there are two reasons why we should wait until 4.1:
- gives users more time to prepare
- gives python 2 people a chance to use the new features (especially
demeshening) at least for one 4.x version
On Apr 20, 2017, at 5:27 PM, Michael Zingale < michael.zingale@stonybrook.edu> wrote:
my thought on this is that removing python 2 support should occur on a major release, not a point release. It seems odd that yt 4.0 supports both 2 and 3, but 4.1 drops python 2 support. Might be confusing for users.
On Thu, Apr 20, 2017 at 4:27 PM, Matthew Turk matthewturk@gmail.com wrote:
Hi folks,
On the call yesterday, the topic of dropping support for Py2 came up. This site provides some context:
http://www.python3statement.org/
At present, we're planning to have a 3.4 release sometime in the early summer, and then aiming for a yt 4.0 sometime about six months later. yt 4.0 will have the demeshening.
A proposal was floated to have yt 4.0 be the last release that explicitly supports python 2, and then to "softly" drop support for python 2 during the cycle for yt 4.1, which would be about six months later, we anticipate. This would mean not testing on py2 anymore and potentially removing some of the shims and six calls to dual-support.
Some more discussion is in the meeting notes:
https://github.com/yt-project/meeting-notes/blob/master/note s-20170419.md
I don't know if this is something we should actively discuss yet, but I wanted to put it out there. I personally support this proposal.
-Matt
yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
-- Michael Zingale Associate Professor
Dept. of Physics & Astronomy • Stony Brook University • Stony Brook, NY 11794-3800 *phone*: 631-632-8225 <(631)%20632-8225> *e-mail*: Michael.Zingale@stonybrook.edu *web*: http://www.astro.sunysb.edu/mzingale github: http://github.com/zingale
yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
On Thu, Apr 20, 2017 at 4:58 PM, Nathan Goldbaum nathan12343@gmail.com wrote:
If we do drop Python2 support, I'd prefer to do it fully and not intentionally leave in six and all of the code that's conditional on Python version. Leaving in the shim code makes the codebase harder to understand, so we should take the opportunity to remove it once we have the chance to make it more approachable and maintainable. In addition, I don't feel comfortable letting people install yt on a version of python that we're intentionally not testing. There should just eventually be a yt version that isn't installable on python2. We will of course need to communicate with out community about that, and announce the transition well ahead of time. Thankfully we are in good company on these announcements, and many other packages (notably IPython) have begun to make their own transitions to python3-only codebases.
Up until now we've tried to avoid having too many breaking changes, and it just so happens that we're thinking about how to handle two of them. The first is the stuff that we want to go into yt 4.0 (non-spatial domains and the demeshening) and the second is dropping Python3. I guess we're most efficient in spending breaking change chits with our userbase if we group these two changes together. Ideally we'd do that, but several people on the call yesterday objected to that but at the same time seemed amenable to the compromise that we drop python3 support soon after releasing a version of yt that includes the demeshening and non-spatial domains. So that means dropping python3 support needs to happen after yt 4.0.
I think Matt would prefer not to to a yt 5.0 release soon after yt 4.0. However, as Mike points out, dropping python3 support is a breaking change for some people, so we probably need to indicate that in the version number. Taken together, I think that means we need to do both a yt 4.0 and yt 5.0 release.
So that means we need to decide now how long we want the delay between releasing yt 4.0 and dropping python3 support in yt 5.0 is going to be. Are we going to release yt 4.1 with new features but still supporting python2? Or are we going to move straight to yt 5.0, possibly supporting yt 4.0 with bugfixes for an extended period. Our messaging here I think depends on what the timeline should be.
If we want to drop python2 support in 2018, I think there should be a yt 4.1.
Sorry, typo, I meant to write I *don't* think there should be a 4.1
If we want to drop it in 2019 or 2020, then we have plenty of time to accumulate other ideas for breaking changes that we want to include in yt 5.0 and we might end up doing yt 4.1 and 4.2 releases.
Personally, I'm leaning towards dropping Python2 support sooner, in 2018. Would anyone prefer a later switch?
On Thu, Apr 20, 2017 at 4:31 PM, Nathan Goldbaum nathan12343@gmail.com wrote:
I guess it doesn't matter much whether we call it 4.1 or 5.0. We could commit ahead of time that the only major breaking change in 5.0 would be dropping python2 support.
On Thu, Apr 20, 2017 at 4:29 PM, John Zuhone jzuhone@gmail.com wrote:
We had a conversation about this point yesterday, in fact I was the one that brought this point up.
Though in my mind I agree with you at first that it makes more sense to do this at 4.0, there are two reasons why we should wait until 4.1:
- gives users more time to prepare
- gives python 2 people a chance to use the new features (especially
demeshening) at least for one 4.x version
On Apr 20, 2017, at 5:27 PM, Michael Zingale < michael.zingale@stonybrook.edu> wrote:
my thought on this is that removing python 2 support should occur on a major release, not a point release. It seems odd that yt 4.0 supports both 2 and 3, but 4.1 drops python 2 support. Might be confusing for users.
On Thu, Apr 20, 2017 at 4:27 PM, Matthew Turk matthewturk@gmail.com wrote:
Hi folks,
On the call yesterday, the topic of dropping support for Py2 came up. This site provides some context:
http://www.python3statement.org/
At present, we're planning to have a 3.4 release sometime in the early summer, and then aiming for a yt 4.0 sometime about six months later. yt 4.0 will have the demeshening.
A proposal was floated to have yt 4.0 be the last release that explicitly supports python 2, and then to "softly" drop support for python 2 during the cycle for yt 4.1, which would be about six months later, we anticipate. This would mean not testing on py2 anymore and potentially removing some of the shims and six calls to dual-support.
Some more discussion is in the meeting notes:
https://github.com/yt-project/meeting-notes/blob/master/note s-20170419.md
I don't know if this is something we should actively discuss yet, but I wanted to put it out there. I personally support this proposal.
-Matt
yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
-- Michael Zingale Associate Professor
Dept. of Physics & Astronomy • Stony Brook University • Stony Brook, NY 11794-3800 *phone*: 631-632-8225 <(631)%20632-8225> *e-mail*: Michael.Zingale@stonybrook.edu *web*: http://www.astro.sunysb.edu/mzingale github: http://github.com/zingale
yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
Sometime in 2018 sounds like a very reasonable time for dropping python2.7 support. What is most important to me is giving the users enough warning and time to switch before this happens. It matter less to me what type of release it happens on.
The 4.0 release will be hugely beneficial for so many people (specifically for it's improved SPH support) that I think it's important that we maintain python2 support until then. I think it's the kinder thing to do than to make 4.0 the carrot offered for switching to python3. I'm also guessing that everything that's being developed for 4.0 still works with python2, so we might as well keep that up until the release.
I think the 3.4 release will be a good opportunity to announce that there is a timeline for dropping python2 support, and specifically to say that there will only be one more release and then python2 is gone. Then, 4.0 comes out and we say this is it, time to switch.
My two cents! Time to board a flight!
On Thu, Apr 20, 2017 at 3:03 PM, Nathan Goldbaum nathan12343@gmail.com wrote:
On Thu, Apr 20, 2017 at 4:58 PM, Nathan Goldbaum nathan12343@gmail.com wrote:
If we do drop Python2 support, I'd prefer to do it fully and not intentionally leave in six and all of the code that's conditional on Python version. Leaving in the shim code makes the codebase harder to understand, so we should take the opportunity to remove it once we have the chance to make it more approachable and maintainable. In addition, I don't feel comfortable letting people install yt on a version of python that we're intentionally not testing. There should just eventually be a yt version that isn't installable on python2. We will of course need to communicate with out community about that, and announce the transition well ahead of time. Thankfully we are in good company on these announcements, and many other packages (notably IPython) have begun to make their own transitions to python3-only codebases.
Up until now we've tried to avoid having too many breaking changes, and it just so happens that we're thinking about how to handle two of them. The first is the stuff that we want to go into yt 4.0 (non-spatial domains and the demeshening) and the second is dropping Python3. I guess we're most efficient in spending breaking change chits with our userbase if we group these two changes together. Ideally we'd do that, but several people on the call yesterday objected to that but at the same time seemed amenable to the compromise that we drop python3 support soon after releasing a version of yt that includes the demeshening and non-spatial domains. So that means dropping python3 support needs to happen after yt 4.0.
I think Matt would prefer not to to a yt 5.0 release soon after yt 4.0. However, as Mike points out, dropping python3 support is a breaking change for some people, so we probably need to indicate that in the version number. Taken together, I think that means we need to do both a yt 4.0 and yt 5.0 release.
So that means we need to decide now how long we want the delay between releasing yt 4.0 and dropping python3 support in yt 5.0 is going to be. Are we going to release yt 4.1 with new features but still supporting python2? Or are we going to move straight to yt 5.0, possibly supporting yt 4.0 with bugfixes for an extended period. Our messaging here I think depends on what the timeline should be.
If we want to drop python2 support in 2018, I think there should be a yt 4.1.
Sorry, typo, I meant to write I *don't* think there should be a 4.1
If we want to drop it in 2019 or 2020, then we have plenty of time to accumulate other ideas for breaking changes that we want to include in yt 5.0 and we might end up doing yt 4.1 and 4.2 releases.
Personally, I'm leaning towards dropping Python2 support sooner, in 2018. Would anyone prefer a later switch?
On Thu, Apr 20, 2017 at 4:31 PM, Nathan Goldbaum nathan12343@gmail.com wrote:
I guess it doesn't matter much whether we call it 4.1 or 5.0. We could commit ahead of time that the only major breaking change in 5.0 would be dropping python2 support.
On Thu, Apr 20, 2017 at 4:29 PM, John Zuhone jzuhone@gmail.com wrote:
We had a conversation about this point yesterday, in fact I was the one that brought this point up.
Though in my mind I agree with you at first that it makes more sense to do this at 4.0, there are two reasons why we should wait until 4.1:
- gives users more time to prepare
- gives python 2 people a chance to use the new features (especially
demeshening) at least for one 4.x version
On Apr 20, 2017, at 5:27 PM, Michael Zingale < michael.zingale@stonybrook.edu> wrote:
my thought on this is that removing python 2 support should occur on a major release, not a point release. It seems odd that yt 4.0 supports both 2 and 3, but 4.1 drops python 2 support. Might be confusing for users.
On Thu, Apr 20, 2017 at 4:27 PM, Matthew Turk matthewturk@gmail.com wrote:
Hi folks,
On the call yesterday, the topic of dropping support for Py2 came up. This site provides some context:
http://www.python3statement.org/
At present, we're planning to have a 3.4 release sometime in the early summer, and then aiming for a yt 4.0 sometime about six months later. yt 4.0 will have the demeshening.
A proposal was floated to have yt 4.0 be the last release that explicitly supports python 2, and then to "softly" drop support for python 2 during the cycle for yt 4.1, which would be about six months later, we anticipate. This would mean not testing on py2 anymore and potentially removing some of the shims and six calls to dual-support.
Some more discussion is in the meeting notes:
https://github.com/yt-project/meeting-notes/blob/master/note s-20170419.md
I don't know if this is something we should actively discuss yet, but I wanted to put it out there. I personally support this proposal.
-Matt
yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
-- Michael Zingale Associate Professor
Dept. of Physics & Astronomy • Stony Brook University • Stony Brook, NY 11794-3800 *phone*: 631-632-8225 <(631)%20632-8225> *e-mail*: Michael.Zingale@stonybrook.edu *web*: http://www.astro.sunysb.edu/mzingale github: http://github.com/zingale
yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
As I mentioned during the meeting, I like the idea of having some sort of long term support for the release prior to the switch, so that people have the choice of continuing to use a version of yt with python 2.x support before having the rug pulled out from under them in a few months. I realize that this is not a trivial thing to do, though, so I'm flexible.
Cameron
On Fri, Apr 21, 2017 at 10:40 AM, Britton Smith brittonsmith@gmail.com wrote:
Sometime in 2018 sounds like a very reasonable time for dropping python2.7 support. What is most important to me is giving the users enough warning and time to switch before this happens. It matter less to me what type of release it happens on.
The 4.0 release will be hugely beneficial for so many people (specifically for it's improved SPH support) that I think it's important that we maintain python2 support until then. I think it's the kinder thing to do than to make 4.0 the carrot offered for switching to python3. I'm also guessing that everything that's being developed for 4.0 still works with python2, so we might as well keep that up until the release.
I think the 3.4 release will be a good opportunity to announce that there is a timeline for dropping python2 support, and specifically to say that there will only be one more release and then python2 is gone. Then, 4.0 comes out and we say this is it, time to switch.
My two cents! Time to board a flight!
On Thu, Apr 20, 2017 at 3:03 PM, Nathan Goldbaum nathan12343@gmail.com wrote:
On Thu, Apr 20, 2017 at 4:58 PM, Nathan Goldbaum nathan12343@gmail.com wrote:
If we do drop Python2 support, I'd prefer to do it fully and not intentionally leave in six and all of the code that's conditional on Python version. Leaving in the shim code makes the codebase harder to understand, so we should take the opportunity to remove it once we have the chance to make it more approachable and maintainable. In addition, I don't feel comfortable letting people install yt on a version of python that we're intentionally not testing. There should just eventually be a yt version that isn't installable on python2. We will of course need to communicate with out community about that, and announce the transition well ahead of time. Thankfully we are in good company on these announcements, and many other packages (notably IPython) have begun to make their own transitions to python3-only codebases.
Up until now we've tried to avoid having too many breaking changes, and it just so happens that we're thinking about how to handle two of them. The first is the stuff that we want to go into yt 4.0 (non-spatial domains and the demeshening) and the second is dropping Python3. I guess we're most efficient in spending breaking change chits with our userbase if we group these two changes together. Ideally we'd do that, but several people on the call yesterday objected to that but at the same time seemed amenable to the compromise that we drop python3 support soon after releasing a version of yt that includes the demeshening and non-spatial domains. So that means dropping python3 support needs to happen after yt 4.0.
I think Matt would prefer not to to a yt 5.0 release soon after yt 4.0. However, as Mike points out, dropping python3 support is a breaking change for some people, so we probably need to indicate that in the version number. Taken together, I think that means we need to do both a yt 4.0 and yt 5.0 release.
So that means we need to decide now how long we want the delay between releasing yt 4.0 and dropping python3 support in yt 5.0 is going to be. Are we going to release yt 4.1 with new features but still supporting python2? Or are we going to move straight to yt 5.0, possibly supporting yt 4.0 with bugfixes for an extended period. Our messaging here I think depends on what the timeline should be.
If we want to drop python2 support in 2018, I think there should be a yt 4.1.
Sorry, typo, I meant to write I *don't* think there should be a 4.1
If we want to drop it in 2019 or 2020, then we have plenty of time to accumulate other ideas for breaking changes that we want to include in yt 5.0 and we might end up doing yt 4.1 and 4.2 releases.
Personally, I'm leaning towards dropping Python2 support sooner, in 2018. Would anyone prefer a later switch?
On Thu, Apr 20, 2017 at 4:31 PM, Nathan Goldbaum nathan12343@gmail.com wrote:
I guess it doesn't matter much whether we call it 4.1 or 5.0. We could commit ahead of time that the only major breaking change in 5.0 would be dropping python2 support.
On Thu, Apr 20, 2017 at 4:29 PM, John Zuhone jzuhone@gmail.com wrote:
We had a conversation about this point yesterday, in fact I was the one that brought this point up.
Though in my mind I agree with you at first that it makes more sense to do this at 4.0, there are two reasons why we should wait until 4.1:
- gives users more time to prepare
- gives python 2 people a chance to use the new features (especially
demeshening) at least for one 4.x version
On Apr 20, 2017, at 5:27 PM, Michael Zingale < michael.zingale@stonybrook.edu> wrote:
my thought on this is that removing python 2 support should occur on a major release, not a point release. It seems odd that yt 4.0 supports both 2 and 3, but 4.1 drops python 2 support. Might be confusing for users.
On Thu, Apr 20, 2017 at 4:27 PM, Matthew Turk matthewturk@gmail.com wrote:
Hi folks,
On the call yesterday, the topic of dropping support for Py2 came up. This site provides some context:
http://www.python3statement.org/
At present, we're planning to have a 3.4 release sometime in the early summer, and then aiming for a yt 4.0 sometime about six months later. yt 4.0 will have the demeshening.
A proposal was floated to have yt 4.0 be the last release that explicitly supports python 2, and then to "softly" drop support for python 2 during the cycle for yt 4.1, which would be about six months later, we anticipate. This would mean not testing on py2 anymore and potentially removing some of the shims and six calls to dual-support.
Some more discussion is in the meeting notes:
https://github.com/yt-project/meeting-notes/blob/master/note s-20170419.md
I don't know if this is something we should actively discuss yet, but I wanted to put it out there. I personally support this proposal.
-Matt
yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
-- Michael Zingale Associate Professor
Dept. of Physics & Astronomy • Stony Brook University • Stony Brook, NY 11794-3800 *phone*: 631-632-8225 <(631)%20632-8225> *e-mail*: Michael.Zingale@stonybrook.edu *web*: http://www.astro.sunysb.edu/mzingale github: http://github.com/zingale
yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
participants (6)
-
Britton Smith -
Cameron Hummels -
John Zuhone -
Matthew Turk -
Michael Zingale -
Nathan Goldbaum