lib: restore python 2.6 in semverRange for v5.x

[rvagg]

Dropped accidentally in backport @
#1910

The change to >=2.7 was declared semver-major in
#1813

@sam-github@cclauss@joaocgreis this blocks 5.0.5. If nobody disagrees I might just squash this into the commit that I landed in v5.x for #1910 as if it was right all along. It'll mean rewriting a few commits on the HEAD of v5.x.

[rvagg]

@sam-github thanks for the approval, I just pushed a change to make it ^2.6.0 || >= 3.5.0, the original one allowed anything >=2.6. I'm going to assume tests passing gives me the +1 on that change unless you want to re-approve.

[cclauss]

We do not support Python 2.6, 3.0, 3.1, 3.2, 3.3, or 3.4. They are all EOL. Our Python 3 conversion code was not tested on these EOL platforms and is known to break in them. https://www.google.ch/amp/s/snarky.ca/stop-using-python-2-6/amp/ Was written by the Python Core Team four years ago.

[cclauss]

I object. Python 2.6 was EoLed in 2013. https://devguide.python.org/devcycle/#end-of-life-branches This is known to fail. Please add tests on Travis and/or Jenkins to prove that each of these EoLed versions pass our tests.

[sam-github]

Unless we know for certain that 2.6 doesn't work, shipping an update "patch" release that can cause people with working 2.6 systems to stop getting builds doesn't seem to have a point.

@cclauss 6.x can forbid 2.6, why do it in 5.x?

[cclauss]

We don’t know anything about Python 2.6 because we do not test on it.

On Travis, we should be able to dist: precise and python: 2.6 and run our tests. #1913

If they pass then I will withdrawn my objection.

[rvagg]

we're not going to increase the semver check from 2.6 to 2.7 on 5.x, that's one of the things 6.x is for. It was mistakenly bumped in the backport, this restores it to what it was prior to that commit. I'll remove mention of 2.6 from the docs, the semverRange check has to be restored to what it was on 5.0.4 though.

[rvagg]

removed mention of 2.6 in #1911, it's only "supported" in the sense that we don't reject it in our semverRange, whether that works for people or not is not if we don't state that it's compatible with it. We just can't change semverRange outside of a sevmer-major.

[cclauss]

Dropping my objection. Let’s wrap up v5.x and move onto v6...

[cclauss]

Please proceed despite #1913... It is time to move forward to v6.x

[rvagg]

squashed into the #1910 commit as 07f81f1, minor reorg of the HEAD of v5.x and force pushed up

[rvagg]

Dropped accidentally in backport @
#1910

The change to >=2.7 was declared semver-major in
#1813

@sam-github@cclauss@joaocgreis this blocks 5.0.5. If nobody disagrees I might just squash this into the commit that I landed in v5.x for #1910 as if it was right all along. It'll mean rewriting a few commits on the HEAD of v5.x.

[rvagg]

@sam-github thanks for the approval, I just pushed a change to make it ^2.6.0 || >= 3.5.0, the original one allowed anything >=2.6. I'm going to assume tests passing gives me the +1 on that change unless you want to re-approve.

[cclauss]

We do not support Python 2.6, 3.0, 3.1, 3.2, 3.3, or 3.4. They are all EOL. Our Python 3 conversion code was not tested on these EOL platforms and is known to break in them. https://www.google.ch/amp/s/snarky.ca/stop-using-python-2-6/amp/ Was written by the Python Core Team four years ago.

[cclauss]

I object. Python 2.6 was EoLed in 2013. https://devguide.python.org/devcycle/#end-of-life-branches This is known to fail. Please add tests on Travis and/or Jenkins to prove that each of these EoLed versions pass our tests.

[sam-github]

Unless we know for certain that 2.6 doesn't work, shipping an update "patch" release that can cause people with working 2.6 systems to stop getting builds doesn't seem to have a point.

@cclauss 6.x can forbid 2.6, why do it in 5.x?

[cclauss]

We don’t know anything about Python 2.6 because we do not test on it.

On Travis, we should be able to dist: precise and python: 2.6 and run our tests. #1913

If they pass then I will withdrawn my objection.

[rvagg]

we're not going to increase the semver check from 2.6 to 2.7 on 5.x, that's one of the things 6.x is for. It was mistakenly bumped in the backport, this restores it to what it was prior to that commit. I'll remove mention of 2.6 from the docs, the semverRange check has to be restored to what it was on 5.0.4 though.

[rvagg]

removed mention of 2.6 in #1911, it's only "supported" in the sense that we don't reject it in our semverRange, whether that works for people or not is not if we don't state that it's compatible with it. We just can't change semverRange outside of a sevmer-major.

[cclauss]

Dropping my objection. Let’s wrap up v5.x and move onto v6...

[cclauss]

Please proceed despite #1913... It is time to move forward to v6.x

[rvagg]

squashed into the #1910 commit as 07f81f1, minor reorg of the HEAD of v5.x and force pushed up

[rvagg]

Dropped accidentally in backport @
#1910

The change to >=2.7 was declared semver-major in
#1813

@sam-github@cclauss@joaocgreis this blocks 5.0.5. If nobody disagrees I might just squash this into the commit that I landed in v5.x for #1910 as if it was right all along. It'll mean rewriting a few commits on the HEAD of v5.x.

[rvagg]

@sam-github thanks for the approval, I just pushed a change to make it ^2.6.0 || >= 3.5.0, the original one allowed anything >=2.6. I'm going to assume tests passing gives me the +1 on that change unless you want to re-approve.

[cclauss]

We do not support Python 2.6, 3.0, 3.1, 3.2, 3.3, or 3.4. They are all EOL. Our Python 3 conversion code was not tested on these EOL platforms and is known to break in them. https://www.google.ch/amp/s/snarky.ca/stop-using-python-2-6/amp/ Was written by the Python Core Team four years ago.

[cclauss]

I object. Python 2.6 was EoLed in 2013. https://devguide.python.org/devcycle/#end-of-life-branches This is known to fail. Please add tests on Travis and/or Jenkins to prove that each of these EoLed versions pass our tests.

[sam-github]

Unless we know for certain that 2.6 doesn't work, shipping an update "patch" release that can cause people with working 2.6 systems to stop getting builds doesn't seem to have a point.

@cclauss 6.x can forbid 2.6, why do it in 5.x?

[cclauss]

We don’t know anything about Python 2.6 because we do not test on it.

On Travis, we should be able to dist: precise and python: 2.6 and run our tests. #1913

If they pass then I will withdrawn my objection.

[rvagg]

we're not going to increase the semver check from 2.6 to 2.7 on 5.x, that's one of the things 6.x is for. It was mistakenly bumped in the backport, this restores it to what it was prior to that commit. I'll remove mention of 2.6 from the docs, the semverRange check has to be restored to what it was on 5.0.4 though.

[rvagg]

removed mention of 2.6 in #1911, it's only "supported" in the sense that we don't reject it in our semverRange, whether that works for people or not is not if we don't state that it's compatible with it. We just can't change semverRange outside of a sevmer-major.

[cclauss]

Dropping my objection. Let’s wrap up v5.x and move onto v6...

[cclauss]

Please proceed despite #1913... It is time to move forward to v6.x

[rvagg]

squashed into the #1910 commit as 07f81f1, minor reorg of the HEAD of v5.x and force pushed up

[rvagg]

Dropped accidentally in backport @
#1910

The change to >=2.7 was declared semver-major in
#1813

@sam-github@cclauss@joaocgreis this blocks 5.0.5. If nobody disagrees I might just squash this into the commit that I landed in v5.x for #1910 as if it was right all along. It'll mean rewriting a few commits on the HEAD of v5.x.

[rvagg]

@sam-github thanks for the approval, I just pushed a change to make it ^2.6.0 || >= 3.5.0, the original one allowed anything >=2.6. I'm going to assume tests passing gives me the +1 on that change unless you want to re-approve.

[cclauss]

We do not support Python 2.6, 3.0, 3.1, 3.2, 3.3, or 3.4. They are all EOL. Our Python 3 conversion code was not tested on these EOL platforms and is known to break in them. https://www.google.ch/amp/s/snarky.ca/stop-using-python-2-6/amp/ Was written by the Python Core Team four years ago.

[cclauss]

I object. Python 2.6 was EoLed in 2013. https://devguide.python.org/devcycle/#end-of-life-branches This is known to fail. Please add tests on Travis and/or Jenkins to prove that each of these EoLed versions pass our tests.

[sam-github]

Unless we know for certain that 2.6 doesn't work, shipping an update "patch" release that can cause people with working 2.6 systems to stop getting builds doesn't seem to have a point.

@cclauss 6.x can forbid 2.6, why do it in 5.x?

[cclauss]

We don’t know anything about Python 2.6 because we do not test on it.

On Travis, we should be able to dist: precise and python: 2.6 and run our tests. #1913

If they pass then I will withdrawn my objection.

[rvagg]

we're not going to increase the semver check from 2.6 to 2.7 on 5.x, that's one of the things 6.x is for. It was mistakenly bumped in the backport, this restores it to what it was prior to that commit. I'll remove mention of 2.6 from the docs, the semverRange check has to be restored to what it was on 5.0.4 though.

[rvagg]

removed mention of 2.6 in #1911, it's only "supported" in the sense that we don't reject it in our semverRange, whether that works for people or not is not if we don't state that it's compatible with it. We just can't change semverRange outside of a sevmer-major.

[cclauss]

Dropping my objection. Let’s wrap up v5.x and move onto v6...

[cclauss]

Please proceed despite #1913... It is time to move forward to v6.x

[rvagg]

squashed into the #1910 commit as 07f81f1, minor reorg of the HEAD of v5.x and force pushed up

[rvagg]

Dropped accidentally in backport @
#1910

The change to >=2.7 was declared semver-major in
#1813

@sam-github@cclauss@joaocgreis this blocks 5.0.5. If nobody disagrees I might just squash this into the commit that I landed in v5.x for #1910 as if it was right all along. It'll mean rewriting a few commits on the HEAD of v5.x.

[rvagg]

@sam-github thanks for the approval, I just pushed a change to make it ^2.6.0 || >= 3.5.0, the original one allowed anything >=2.6. I'm going to assume tests passing gives me the +1 on that change unless you want to re-approve.

[cclauss]

We do not support Python 2.6, 3.0, 3.1, 3.2, 3.3, or 3.4. They are all EOL. Our Python 3 conversion code was not tested on these EOL platforms and is known to break in them. https://www.google.ch/amp/s/snarky.ca/stop-using-python-2-6/amp/ Was written by the Python Core Team four years ago.

[cclauss]

I object. Python 2.6 was EoLed in 2013. https://devguide.python.org/devcycle/#end-of-life-branches This is known to fail. Please add tests on Travis and/or Jenkins to prove that each of these EoLed versions pass our tests.

[sam-github]

Unless we know for certain that 2.6 doesn't work, shipping an update "patch" release that can cause people with working 2.6 systems to stop getting builds doesn't seem to have a point.

@cclauss 6.x can forbid 2.6, why do it in 5.x?

[cclauss]

We don’t know anything about Python 2.6 because we do not test on it.

On Travis, we should be able to dist: precise and python: 2.6 and run our tests. #1913

If they pass then I will withdrawn my objection.

[rvagg]

we're not going to increase the semver check from 2.6 to 2.7 on 5.x, that's one of the things 6.x is for. It was mistakenly bumped in the backport, this restores it to what it was prior to that commit. I'll remove mention of 2.6 from the docs, the semverRange check has to be restored to what it was on 5.0.4 though.

[rvagg]

removed mention of 2.6 in #1911, it's only "supported" in the sense that we don't reject it in our semverRange, whether that works for people or not is not if we don't state that it's compatible with it. We just can't change semverRange outside of a sevmer-major.

[cclauss]

Dropping my objection. Let’s wrap up v5.x and move onto v6...

[cclauss]

Please proceed despite #1913... It is time to move forward to v6.x

[rvagg]

squashed into the #1910 commit as 07f81f1, minor reorg of the HEAD of v5.x and force pushed up

[rvagg]

Dropped accidentally in backport @
#1910

The change to >=2.7 was declared semver-major in
#1813

@sam-github@cclauss@joaocgreis this blocks 5.0.5. If nobody disagrees I might just squash this into the commit that I landed in v5.x for #1910 as if it was right all along. It'll mean rewriting a few commits on the HEAD of v5.x.

[rvagg]

@sam-github thanks for the approval, I just pushed a change to make it ^2.6.0 || >= 3.5.0, the original one allowed anything >=2.6. I'm going to assume tests passing gives me the +1 on that change unless you want to re-approve.

[cclauss]

We do not support Python 2.6, 3.0, 3.1, 3.2, 3.3, or 3.4. They are all EOL. Our Python 3 conversion code was not tested on these EOL platforms and is known to break in them. https://www.google.ch/amp/s/snarky.ca/stop-using-python-2-6/amp/ Was written by the Python Core Team four years ago.

[cclauss]

I object. Python 2.6 was EoLed in 2013. https://devguide.python.org/devcycle/#end-of-life-branches This is known to fail. Please add tests on Travis and/or Jenkins to prove that each of these EoLed versions pass our tests.

[sam-github]

Unless we know for certain that 2.6 doesn't work, shipping an update "patch" release that can cause people with working 2.6 systems to stop getting builds doesn't seem to have a point.

@cclauss 6.x can forbid 2.6, why do it in 5.x?

[cclauss]

We don’t know anything about Python 2.6 because we do not test on it.

On Travis, we should be able to dist: precise and python: 2.6 and run our tests. #1913

If they pass then I will withdrawn my objection.

[rvagg]

we're not going to increase the semver check from 2.6 to 2.7 on 5.x, that's one of the things 6.x is for. It was mistakenly bumped in the backport, this restores it to what it was prior to that commit. I'll remove mention of 2.6 from the docs, the semverRange check has to be restored to what it was on 5.0.4 though.

[rvagg]

removed mention of 2.6 in #1911, it's only "supported" in the sense that we don't reject it in our semverRange, whether that works for people or not is not if we don't state that it's compatible with it. We just can't change semverRange outside of a sevmer-major.

[cclauss]

Dropping my objection. Let’s wrap up v5.x and move onto v6...

[cclauss]

Please proceed despite #1913... It is time to move forward to v6.x

[rvagg]

squashed into the #1910 commit as 07f81f1, minor reorg of the HEAD of v5.x and force pushed up

[rvagg]

Dropped accidentally in backport @
#1910

The change to >=2.7 was declared semver-major in
#1813

@sam-github@cclauss@joaocgreis this blocks 5.0.5. If nobody disagrees I might just squash this into the commit that I landed in v5.x for #1910 as if it was right all along. It'll mean rewriting a few commits on the HEAD of v5.x.

[rvagg]

@sam-github thanks for the approval, I just pushed a change to make it ^2.6.0 || >= 3.5.0, the original one allowed anything >=2.6. I'm going to assume tests passing gives me the +1 on that change unless you want to re-approve.

[cclauss]

We do not support Python 2.6, 3.0, 3.1, 3.2, 3.3, or 3.4. They are all EOL. Our Python 3 conversion code was not tested on these EOL platforms and is known to break in them. https://www.google.ch/amp/s/snarky.ca/stop-using-python-2-6/amp/ Was written by the Python Core Team four years ago.

[cclauss]

I object. Python 2.6 was EoLed in 2013. https://devguide.python.org/devcycle/#end-of-life-branches This is known to fail. Please add tests on Travis and/or Jenkins to prove that each of these EoLed versions pass our tests.

[sam-github]

Unless we know for certain that 2.6 doesn't work, shipping an update "patch" release that can cause people with working 2.6 systems to stop getting builds doesn't seem to have a point.

@cclauss 6.x can forbid 2.6, why do it in 5.x?

[cclauss]

We don’t know anything about Python 2.6 because we do not test on it.

On Travis, we should be able to dist: precise and python: 2.6 and run our tests. #1913

If they pass then I will withdrawn my objection.

[rvagg]

we're not going to increase the semver check from 2.6 to 2.7 on 5.x, that's one of the things 6.x is for. It was mistakenly bumped in the backport, this restores it to what it was prior to that commit. I'll remove mention of 2.6 from the docs, the semverRange check has to be restored to what it was on 5.0.4 though.

[rvagg]

removed mention of 2.6 in #1911, it's only "supported" in the sense that we don't reject it in our semverRange, whether that works for people or not is not if we don't state that it's compatible with it. We just can't change semverRange outside of a sevmer-major.

[cclauss]

Dropping my objection. Let’s wrap up v5.x and move onto v6...

[cclauss]

Please proceed despite #1913... It is time to move forward to v6.x

[rvagg]

squashed into the #1910 commit as 07f81f1, minor reorg of the HEAD of v5.x and force pushed up

[rvagg]

Dropped accidentally in backport @
#1910

The change to >=2.7 was declared semver-major in
#1813

@sam-github@cclauss@joaocgreis this blocks 5.0.5. If nobody disagrees I might just squash this into the commit that I landed in v5.x for #1910 as if it was right all along. It'll mean rewriting a few commits on the HEAD of v5.x.

[rvagg]

@sam-github thanks for the approval, I just pushed a change to make it ^2.6.0 || >= 3.5.0, the original one allowed anything >=2.6. I'm going to assume tests passing gives me the +1 on that change unless you want to re-approve.

[cclauss]

We do not support Python 2.6, 3.0, 3.1, 3.2, 3.3, or 3.4. They are all EOL. Our Python 3 conversion code was not tested on these EOL platforms and is known to break in them. https://www.google.ch/amp/s/snarky.ca/stop-using-python-2-6/amp/ Was written by the Python Core Team four years ago.

[cclauss]

I object. Python 2.6 was EoLed in 2013. https://devguide.python.org/devcycle/#end-of-life-branches This is known to fail. Please add tests on Travis and/or Jenkins to prove that each of these EoLed versions pass our tests.

[sam-github]

Unless we know for certain that 2.6 doesn't work, shipping an update "patch" release that can cause people with working 2.6 systems to stop getting builds doesn't seem to have a point.

@cclauss 6.x can forbid 2.6, why do it in 5.x?

[cclauss]

We don’t know anything about Python 2.6 because we do not test on it.

On Travis, we should be able to dist: precise and python: 2.6 and run our tests. #1913

If they pass then I will withdrawn my objection.

[rvagg]

we're not going to increase the semver check from 2.6 to 2.7 on 5.x, that's one of the things 6.x is for. It was mistakenly bumped in the backport, this restores it to what it was prior to that commit. I'll remove mention of 2.6 from the docs, the semverRange check has to be restored to what it was on 5.0.4 though.

[rvagg]

removed mention of 2.6 in #1911, it's only "supported" in the sense that we don't reject it in our semverRange, whether that works for people or not is not if we don't state that it's compatible with it. We just can't change semverRange outside of a sevmer-major.

[cclauss]

Dropping my objection. Let’s wrap up v5.x and move onto v6...

[cclauss]

Please proceed despite #1913... It is time to move forward to v6.x

[rvagg]

squashed into the #1910 commit as 07f81f1, minor reorg of the HEAD of v5.x and force pushed up