A question came up while @Dang Liu was updating ATLAS module to use the latest version (0.9.2 -> 2.0.2): How do we handle when a tool gets updated and subcommands change for which modules already exist? In the case of ATLAS, the subtools have not simply been renamed: • Some subcommands got merged with other into a new name (old names removed completely). • Others got renamed. • Others kept their name and functionality. I see three options: 1. Create new modules in existing tool directory. 2. Create new modules in existing tool directory, but delete modules obsolete subcommands. 3. Create a new tool directory

atlas2/

to house the updated modules, leaving the older version modules in

atlas/

What would be the preferred course of action? @Simon Pearce already weighted in on the PR (thank you!), but I wanted to put bring this up in a larger roundtable as well before making any final decisions. 🙂

Is there any reason to keep the older versions around - would someone want to use 0.92 instead of 2.0.2? If not, I agree that the solution would be to deprecate old modules where needed and update/create new ones for the remaining/changed commands

We did this for some gatk modules

i would also say keep all in atlas, add a deprecation message to the ones who are no longer available (but in this case a message like

subtool

is not part of atlas v2 anymore) and if the tool has been replaced add something to the message like (xou can find a similar tool xx)

Personally I really don't like having version specific tool directories, and feel it is only really appropriate in cases where the two versions are being actively used within the community (with no expectation to migrate)

https://github.com/nf-core/modules/blob/62f7fab6a9aa1f9a0a6a2871bdbe632df071d9fe/modules/nf-core/dastool/scaffolds2bin/main.nf See for an example of a deprecation message pointing to another module