[Feature request][Python] Automatically set last stable version

[Kristinita]

1. Summary

It would be nice, if would be possible, that Travis CI can automatically set the latest Python stable version, that developers doesn't need to set specific version.

2. Argumentation

I develop Python packages. I want, that my packages works on latest stable Python version. Part of my example .travis.yml file:

language: python
python:
  - "3.6.4"

When new Python version release, I need to change 3.6.4 to 3.6.5 in each my project, then I should change value to 3.6.6, 3.7.0 and so on. It may take a lot of time.

3. Expected behavior

Example part of .travis.yml:

language: python
python:
  - "stable"

Travis CI will automatically use the latest stable Python version, what is available on Travis CI.

It already realized in Travis CI for nightly Python versions:

language: python
python:
  - "nightly"

Thanks.

[BanzaiMan]

What does "the latest stable Python version" mean? "stable" is not a very good description of that. If the latest version contains a major bug and not stable, should it be considered "stable"?

One thing to keep in mind is that, when a word is used in this way, the cache could become incompatible without notice, and could cause problems.

I understand the usefulness of this feature, but it seems very vague what it really means in terms of implementation.

[lukasgeiter]

Maybe "latest" would be a better name for it?

[acgetchell]

I’m perfectly happy that versions of python, gcc, etc. don’t change while I’m not looking.

As it is, new Travis-CI images may break things in subtle ways — I’m grateful that the team announces these in advance and provide means to use deprecated images.

I build devel nightly for just this reason — last time, it caught the difference in sudo environment handling.

Explicit changes are good.

[Kristinita]

@BanzaiMan, I meant not nightly, beta, dev or pre-release version. Release, that possible download from https://www.python.org/downloads/ page.

I guess, that latest — as @lukasgeiter say — is more correct term.

Thanks.

[cclauss]

Can we all at least agree that the "latest" Python should be the one that is available when group: travis_latest is specified in a .travis.yml file? (This is currently not the case.)

[BanzaiMan]

@cclauss We cannot. Discrepancy between the provisioned build image and the "latest" (whatever that means) is always possible, and is highly likely to remain.

[cclauss]

Understood. I was just going from...

New group values

“group: travis_latest” - Feature Filled

When your work requires recent and freshly updated packages, you can make use of group: travis_latest. We intend to update the fast path frequently and regularly (once a month) with the latest versions of a variety of packages. If you’re working with new feature sets as they roll out or simply want the latest and greatest, this is the path for you.

I do not believe this to be a major issue as specifying the full version (python: "3.6.4") is a reasonable and effective workaround.

[Kristinita]

This issue is still relevant as of December 2023.

Thanks.

[cclauss]

This issue is still relevant...

Only if Travis CI is still relevant after they broke their promise: always free to open source projects.

[acgetchell]

I'm still using Travis-CI for free for my open source project. I email them every so often to request credits, and they happily oblige.