Improve the process around pinning 3rd party tools

[victorlin]

From @corneliusroemer in #222 (comment):

I didn't realize how out of date our pins are compared to conda-base (which is usually using latest versions).

There's still this open PR from 15 months ago: #145

The main argument I see for not updating is that there's no need to, and that there's a risk associated with it.

Downside is that one can't just use latest features of the tools we package, one needs to look at old versions of their docs. And if one wants to use newer features, like e.g. cmaple iqtree, one needs to make explicit PRs for it, like here #226

Related issues/PRs

• Pangolin installation is out of date - should upgrade to v4 #77
• Update pinned software to latest #145

[victorlin]

Copying some discussion from #145.

@tsibley in #145 (comment):

Is there something motivating these updates at this time beyond "because they're possible"?

If not, we should talk more broadly about why/when to make updates like this. Updates for their own sake are not always productive and often counter-productive.

@corneliusroemer in #145 (comment):

@tsibley very happy to talk more broadly about pros/cons of updates and how we'd want to do them, on which schedule etc

I noticed that many pinned tools were quite out of date, so I thought I'll go ahead and see what the most up to date versions are to start a discussion, partially motivated by our recent snakemake update experience.

More regular updates could help us reduce the changes necessary for updates if they become necessary as we'll notice any required changes earlier (once we know we need to change something, new code that is up to date won't need to be changed later) [most code that had to be changed for snakemake upgrade was actually written well after we could have been aware that the code we were writing wouldn't be v7 compatible]

We definitely don't need to update every month, but bringing things up to date every half year or year could be good.

Also, this PR is a good motivation to improve how we test images for compatibility, see #147 (thanks for your work there in #148!)

So, absolutely no rush here, but something that'd be good to tackle.

[victorlin]

and I wrote in #145 (comment) which I'll expand on below:

I think updates are good when there is a specific bugfix or improvement in a newer version that benefits users. Otherwise, they're neutral at best, or even detrimental given potential to introduce newer bugs/incompatibilities just by nature of change.

Admittedly, I'm not on the user side and am often unaware of the latest features that users are missing out on due to pins we've put in place. We've had many group discussions on pinning vs. unpinning, and the general consensus has been to pin. In this sense, the lack of pins in conda-base is the one that is out of alignment and has a TODO, not the other way around.

It sounds like what's needed is a notification system to make potential tooling updates more visible to developers. Maybe we could use GitHub Actions to poll for newer versions of packages and create issues/PRs for developers to consider updating and users to vote on with 👍/👎. We have this system in place using Dependabot on some other repos and I think it works well. Unfortunately I don't think Dependabot can work with the various sources we have in our Dockerfile.