(I'm posting this here instead of D.learn because it isn't really a "How
to do XYZ in D?", but rather to invite discussion on high-level
solutions to a problem.)
Here's a common problem:
1. A project (ex, some library) uses travis-ci (and/or other) to ensure
compatibility with a range of compiler versions. The travis
configuration file includes a manually-curated list of compiler versions.
2. CI tests are triggered by new commits/merges/PRs in the project.
3. New compiler versions are released.
4. Compiler updates may or may not trigger new tests with the new
compiler, depending on the project.
5. Project maintainer must manually update the list of compilers. (And
this isn't one task, but rather O(n), where n=number of projects the
given person is maintaining).
The challenge: What is the best way to automate this? (ie, #4 and #5)
We do already have certain approaches to at least certain facets of the
problem (ex: some third party libs are included in DMD's CI testing),
but there are still limitations and downsides (ex: D tester has limited
resources, and it doesn't address manually updating the travis config's
list of compilers or notifying authors their project's compiler list
needs updated.)
Another sample point of discussion: One possible approach is to have a
bot generate PRs to update project's compiler lists. But that leads to
other questions: How/when is the bot triggered? On what machine does it
run? Is there an existing jumping-off point for creating such a bot? How
does it approach the task of modifying `.travis.yml` (how smart/dumb
does it need to be)? Any security concerns to be mindful of? Etc.
