Closed agjohnson closed 1 year ago
One option could be:
latest
of the upcoming deprecationreadthedocs/build:ubuntu-22.04
as readthedocs/build:latest
stable/testing
?Maybe a brownout of sorts somewhere in there?
Do we have to worry about Python versions at all? I suppose we might have some Python versions available on the old images that were deprecated in the new images
We could also take
latest
to mean "just use whatever is newer" and try ubuntu-22.04 for the build.
This is not 100% possible because build.os
requires build.tools.*
since none of the Ubuntu image have any Python version by default. Besides, I think it's not a good idea to re-use an old config value to mean something completely different now.
Also, I want users to be explicit about what they want to use to avoid reaching a similar state where we are now with latest
being pretty old and also defaulting to Python 3.7 because we weren't able to upgrade without breaking lot of projects.
We can follow the idea of using build.os: ubuntu-latest
proposed in https://github.com/readthedocs/readthedocs.org/issues/8861
Just a bunch of related issues so we can easily find them:
This is not 100% possible because build.os requires build.tools.* since none of the Ubuntu image have any Python version by default.
It seems like what we do need is the template UI and lots of communication then. If we're unwilling to provide users with some default build.tools
, we need every project to upgrade to the new pattern before we can enforce it.
A couple notes for our deprecation plan:
I had in mind that our migration to a configuration file will automatically deprecate these images. However, that's not 100% true and we will need to deal with a specific plan for deprecating these ones. This is because people already using a configuration file v2 with build.image
won't get any notification and are not forced to migrate.
We have 1.6k projects with a build in the last 180 days manually specifying build.image
. This is not a huge number and looks more manageable. However, I think the plan would be similar to our current one for the config file: blog post, onsite and email notification weekly.
Besides, even people that migrate from no-config file to a config file are allowed to use build.image
, since we are not failing those builds. I doubt they are going to do that, tho, but they could.
We have 1.6k projects with a build in the last 180 days manually specifying
build.image
. This is not a huge number and looks more manageable. However, I think the plan would be similar to our current one for the config file: blog post, onsite and email notification weekly.
I re-executed this query using 90 days: https://ethicalads.metabaseapp.com/question/405-projects-specifying-build-image-config-file?days=90 and we have 1k projects specifying build.image
currently
There is an ongoing notification sent weekly and it's planned to drop support on October 16th. I'm closing this issue because there is nothing else to do here.
We keep hitting issues with these images and we are not confident in updating them anymore, so we should start to discuss full deprecation so we're not stuck in limbo, between active maintenance and full deprecation. For some context, 70% of builds are using the
latest
image. This makes the problem harder, as now our least maintained image is the most used.Our new images are much nicer to use, and most users should be able to upgrade. However, this is probably something we want make the responsibility of the project maintainers. At least to start. At some point we probably want to throw errors on builds when the image is in use.
We could also take
latest
to mean "just use whatever is newer" and try ubuntu-22.04 for the build.Plan
TBD