seqr versioning/sync

[jxchong]

We're trying to figure out how we can tell whether the version of our local seqr GUI/instance that we are using in-browser is in sync with your repository. Normally we would have our seqr show a version number that corresponds to the version built in yours, but the current system of random cache IDs makes tracing difficult. Are there any thoughts about moving towards concurrent versioning numbers or do you have a suggestion for how to trace cache numbers when we're merging into our custom repo? The goal is so if an end-user reports a bug and it turns out to be a bug that was fixed in this repo (or new feature was added), they can tell whether the seqr they are currently using should have the fix or not.

[hanars]

So it used to be the displayed version in the footer matched the asset hash in the seqr codebase, so it wasn't a random version it actually had meaning and was verifiable. However, a couple weeks ago we changed the way we build assets so now the asset version in the footer never matches the version in the code base, so its no longer a reasonable versioning approach. @sjahl is on vacation this week, but he is the person who has been working on upgrading our deployment process, and he might have some ideas of how we can help solve this issue. The best idea I can come up with is to have seqr use a commit hash in the version to be clear what commit is running, but I'm not sure that helps

[sjahl]

@jxchong Are you deploying seqr using our published Docker images, or in some other manner (it sounds like you may not be using our images if you're merging code back into a custom repo)?

I think associating your version of seqr with ours has more to do with how you're merging code back into your repository -- i.e. you should probably be keeping track of or recording the git commit SHA of upstream seqr when updating your repository. While it was possible to compare javascript asset hashes previously, that was a loose connection to the actual version of seqr anyhow, since it was possible that we'd have released an update that contained no UI changes that would have prompted a new hash ID.

That being said, it would definitely make things easier for people building custom seqr instances if we propagated a version number somewhere. I could see us making better use of the Github Releases feature to better highlight updates and stamping a version number when we generate a release. I'll have to discuss this with @hanars and the seqr team.

[hanars]

One thing we could do is update the version we show in the seqr footer to come from a release number/ github commit hash. But I would think you would want to have the version you see in some way linked to your own code version as well as ours

[jxchong]

Definitely a version number would be very useful (also thinking forwards towards publication, being able to state "analysis was performed on seqr release 34" is more informative than "analysis was performed on seqr 1d894a").

Our current plan until you have a release number is to manually include your repo's commit hash in the comments of our merge commit, and then to have our footer reflect our github commit hash, so it'll be a two-step process to trace back and require manual updating.