Great catch! Renaming the tag to jvm-groovy as you suggested is a good idea. Editing the usage guidance should also be done if the tag is renamed, but just fixing the usage guidance alone is very unlikely to prevent the tag from being misused.

Version tags are available (although some folks feel they should not be used at all) in the form 16.04 18.04 20.04 20.10 etc. Usually we have synonymised them so that xenial maps to 16.04 (attempts to use the former add the latter. We could do the same with groovy if we rename the current groovy.

Great catch! Renaming the tag to jvm-groovy as you suggested is a good idea. Editing the usage guidance should also be done if the tag is renamed, but just fixing the usage guidance alone is very unlikely to prevent the tag from being misused.

Version tags are available (although some folks feel they should not be used at all) in the form 16.04 18.04 20.04 20.10 etc. Usually we have synonymised them so that, for example, xenial maps to 16.04 (attempts to use the former add the latter). We could do the same with groovy if we rename the current groovy.

Great catch! Renaming the tag to jvm-groovy as you suggested is a good idea. Editing the usage guidance should also be done if the tag is renamed, but just fixing the usage guidance alone is very unlikely to prevent the tag from being misused.

Version tags are available (although some folks feel they should not be used at all) in the form 16.04 18.04 20.04 20.10 etc.

Great catch! Renaming the tag to jvm-groovy as you suggested is a good idea. Editing the usage guidance should also be done if the tag is renamed, but just fixing the usage guidance alone is very unlikely to prevent the tag from being misused.

Version tags are available (although some folks feel they should not be used at all) in the form 16.04 18.04 20.04 20.10 etc. Usually we have synonymised them so that xenial maps to 16.04 (attempts to use the former add the latter. We could do the same with groovy if we rename the current groovy.