Since the only technical objection so far has a workaround and no one’s clamoring for maintainership, it seems like intentional deprecation and eventual removal is still the obvious path forward.
I imagine something like:
We pick a date or version to end support by. I’m using “October 1” for illustration without much thought.
Develop & host a resource somewhere (distinct page? github issue? discourse thread? Wiki page? Gist? New repo?) that explains:
- why support is ending
- how to transition your project to github actions
PR an update to the Nix builder for travis-ci to:
- Error out before installing Nix unless a new environment variable is present. Give this variable a name like
- Add a deprecation warning message (printed with the error above and in the “Nix support for Travis CI is community maintained…” announcement) that:
- explains we’re ending support on or after October 1, 2020
- points to a URL with more on how they should update their projects
Prepare doc/build PRs to implement the eventual removal and open them as drafts so that we can spend a little time working with someone at travis-ci on what the final step should look like. I couldn’t find clear evidence that someone’s ended community support for a language yet, nor do I see any documented process for doing it, so it may take them a bit to decide. I assume they’ll want to leave stubs behind to throw removal notices and such.
Optional/optimistic: If we can find a good way to build a prioritized list of active projects that are using travis-ci with Nix (and find a few people on our end with a little spare energy…) I think it would be a nice gesture to PR working Github Actions configs that ~match their travis-ci configs.
If the PR or deprecation efforts create enough noise to make it obvious there’s still demand specific to travis-ci (but fails to locate 3 maintainers–the minimum travis-ci cites for a community-supported language), it may make sense to continue with deprecation/removal but also host a repo with an install script and instructions on how users can add it to their
.travis.yml for less-official support. I’m not a fan of this, but I think it would at least be less tedious to iterate on.