Please consider all-numeric x.y.z versions + graduate from alpha

[Henrik Bengtsson]

Please consider using all-numeric `x.y.z` versions, instead of `x.y(a|b).z.zz` (see below). An all-numeric version number is much easier to compare programmatically, whereas other formats often require manual inspection.  I maintain a software installation stack of hunreds of tools for HPC users, and it's very rare to see non-x.y.z versions these days, PLINK being one of them.

Also, I've following the PLINK project for years, I always wondered why it's still stuck in "alpha" after all these years, especially since it's so widely used. The v2.00a2-final version is from 2019-12-29, so it's soon be in "alpha" for five years.  I think PLINK 2.0 deserves a 2.0.0 release - especially after all of your hard, great work.  After such a release, I'd recommend to follow, say, semantic versioning, and do 2.0.1, 2.0.2, ... releases after that.

$ git clone g...@github.com:chrchang/plink-ng.git
$ cd plink-ng/
$ git tag | grep -E "^v"
v1.90b3
v1.90b4
v2.00a2-final
v2.00a2.1
v2.00a2.2
v2.00a2.3
v2.00a3-20220218
v2.00a3-20220315
v2.00a3-final
v2.00a3.1
v2.00a3.2
v2.00a3.3
v2.00a3.4
v2.00a3.5
v2.00a3.6
v2.00a3.7
v2.00a4-final
v2.00a4.1
v2.00a4.2
v2.00a4.3
v2.00a4.4
v2.00a4.5
v2.00a4.6
v2.00a4.7
v2.00a4.8
v2.00a4.9
v2.00a5-final
v2.00a5.1
v2.00a5.10
v2.00a5.11
v2.00a5.12
v2.00a5.13
v2.00a5.14
v2.00a5.2
v2.00a5.3
v2.00a5.4
v2.00a5.5
v2.00a5.6
v2.00a5.7
v2.00a5.8

v2.00a5.9

Thanks,

Henrik

[Christopher Chang]

PLINK 2.0 is formally still in alpha because it's still missing enough pieces to often require PLINK 1.9 to be installed alongside it.  This is an unfortunate consequence of deviating too much from the "do one thing and do it well" school of command-line tool design.

However, I will remove the second '0' from the PLINK 1.9 and 2.0 version numbers, and make future tags adhere to the Semantic Versioning 2.0.0 spec.

[Dan Gealow]

Adding on to this request: Currently prebuilt plink 1.9 and plink2 executables are available at URLs of the form:

https://s3.amazonaws.com/plink2-assets/alpha5/plink2_linux_avx2_20241009.zip

so, you need to know the release date of a version in order to download it.

Would it be possible to mirror these URLs with paths that include the version number rather than the date? Maybe something like
https://s3.amazonaws.com/plink2-assets/linux/intel_avx2/plink2_v2.0.0-a.5.16.zip

(not sure if that's possible with s3, if not maybe you could serve redirects from https://www.cog-genomics.org/)

This would allow more straightforward parameterizing of which plink version to download in e.g. dockerfiles. Currently I have to do something like:

ENV PLINK2_FILENAME="plink2_linux_avx2_20241009.zip"

# this has to be manually kept in sync, since you can't make a label

# based on the results of a RUN command like `plink2 --version`

LABEL PLINK2="v2.0.0-a.5.16LM"

RUN mkdir plink2 && cd plink2 \
    && wget https://s3.amazonaws.com/plink2-assets/alpha5/$PLINK2_FILENAME \
    && unzip $PLINK2_FILENAME \
    && rm -f $PLINK2_FILENAME \
    && cp plink2 /usr/local/bin/

I'd like to instead be able to do something like

ENV PLINK2="v2.0.0-a.5.16"

LABEL PLINK2=$PLINK2

RUN mkdir plink2 && cd plink2 \
    && wget https://s3.amazonaws.com/plink2-assets/linux/intel_avx2/plink2_${PLINK2}.zip \

[...]

Thanks for your ongoing work on this tool!

-Dan

P.S. Is there a reason plink 1.9 is still considered "beta"?

[Christopher Chang]

I'll think about a way to simplify this workflow, and implement something by early 2025.

Meanwhile, plink 1.9 is formally still in beta because there are still a few plink 1.07 flags that I haven't made a drop vs. implement decision on.  Yes, I realize it's a bit silly at this point.

[Henrik Bengtsson]

I second Dan wish; it would be very helpful to have deterministic download URLs where the version is part of the URL.  BTW, what does "LM" stand for in PLINK 2.0.0-a.5.16LM?

Also, thanks for making the move(s). If of any help, over in the R world, the author of the quite famous 'ggplot' package, decided to create a new package 'ggplot2' when migrating from v1 to v2. He acknowledged the infamous Version 2 Problem, where so many projects end up with a too daunting task when they want to make major changes going from v1 to v2, and often struggle to wrap the migration up. So, instead the just decided to sunset 'ggplot' but still keeping it around, and start out new with 'ggplot2'. By doing so, they communicated to the world that: I will keep the old 'ggplot' around for a while, but please move to 'ggplot2' and I won't promise backward compatibility - basically, treat as two separate, but similar, software tools.  I think Bowtie did something similar, i.e. bowtie (https://bowtie-bio.sourceforge.net/) and bowtie2 (https://bowtie-bio.sourceforge.net/bowtie2/index.shtml). Maybe you take a similar approach with PLINK v1 and PLINK v2, e.g. rename the latter to PLINK2 and release v2.0.0 as-is now. Then keep referring v1.07 and v1.9alpha as the PLINK v1 project (short 'PLINK').

/Henrik

[Christopher Chang]

I have added URL redirects so that e.g. https://www.cog-genomics.org/static/bin/plink2.0.0-a.6.9_linux_avx2.zip redirects to https://s3.amazonaws.com/plink2-assets/alpha6/plink2_linux_avx2_20250129.zip , so "curl -L --output plink2.0.0-a.6.9_linux_avx2.zip https://www.cog-genomics.org/static/bin/plink2.0.0-a.6.9_linux_avx2.zip" can be used to download by version number and platform.  This only covers 1.9.0-b.7.7, 2.0.0-a.6.9, and 2.0.0-a.5.23 for now, but the plan is to add redirects for all future versions if the approach is satisfactory.

[Christopher Chang]

Unfortunately, my webhost has a limit on the number of redirects I can specify, and I have now hit that limit.  I will keep the existing redirects up for another year, but I need to switch to a different approach for future releases.

Current plan is to attach the zipped compiled binaries as GitHub release Assets (similar to how source code has been automatically attached to e.g. https://github.com/chrchang/plink-ng/releases/tag/v2.0.0-a.6.21 ); does this work for you?

[Chris Chang]

Ok, this has been done for current plink 1.9 and plink 2 releases.

On Thu, Aug 7, 2025 at 11:38 AM Henrik Bengtsson <henrik.b...@gmail.com> wrote:

Releasing versioned source code and binaries via GitHub Releases sounds like an excellent idea. It's quite common these days.

Henrik

--
You received this message because you are subscribed to a topic in the Google Groups "plink2-users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/plink2-users/ltpHZoux3wM/unsubscribe.
To unsubscribe from this group and all its topics, send an email to plink2-users...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/plink2-users/d45dc2b5-98a1-4c5c-a332-416959e885fan%40googlegroups.com.

[Dan Gealow]

Thanks Chris!

A related question, what's the difference between the following versions:
plink2_linux_amd_avx2.zip
plink2_linux_avx2.zip
plink2_linux_i686.zip
plink2_linux_x86_64.zip
and which would you recommend for putting in a container that may be run on different underlying CPUs? (Specifically in my case, various AWS EC2 instances in the C and M series.)

And the same question for the two different plink1.9 linux binaries:
plink_linux_i686.zip
plink_linux_x86_64.zip

-Dan

[Christopher Chang]

"i686" refers to a 32-bit build.  These are only needed on *very* old systems, and are slower and limited to ~2 GB of workspace memory.  You won't have any use for them.

"x86_64" refers to a basic 64-bit build, while "avx2" refers to a 64-bit build using "AVX2" instructions that are supported by most CPUs released since 2013.  I haven't exhaustively checked, but the last EC2 instance types I was aware of which didn't support AVX2 instructions have been retired, so you can probably ignore "x86_64".  The main practical advantage of the AVX2 builds is that sample-subsetting operations, like --keep and --mind, are significantly faster.

The difference between "avx2" and "amd_avx2" lies in the linked linear algebra library; linear-algebra-heavy operations like --pca will be more efficient if the right build for your processor type is used.  EC2 has both AMD and non-AMD instance types, e.g. "m7a" is AMD while "m7i" is Intel.  But if you don't line this bit up properly, it isn't that big of a deal; the AMD-linear-algebra-library build will still produce correct results when executed on an Intel processor, and vice versa.