ss3-source-code icon indicating copy to clipboard operation
ss3-source-code copied to clipboard

[Admin]: Should we migrate all old ss3 executables to GitHub

Open e-perl-NOAA opened this issue 10 months ago • 6 comments

Issue

We got a recent request from someone on the forum for an old SS3 exe, but that user could not download the exe because they did not have a VLAB account.

Possible solutions

  1. Still having the exes of VLAB and adding VLAB users if they need access.
  2. Migrating past releases to a GitHub repo that is just for past releases, either by uploading them as files into a GitHub repo and creating somewhat fake "releases" because the releases wouldn't be associated with any code in that repo
  3. Creating a GitHub discussion and posting all past releases to that discussion.

e-perl-NOAA avatar Mar 24 '25 14:03 e-perl-NOAA

I definitely support creating such a repository and not continuing with VLAB. We recently added Change Logs for past releases, let's consider bringing that into the solution we create here. On my local drive, I have a folder with a subfolder for each release, but only containing Win exe:

Image

Rick-Methot-NOAA avatar Mar 24 '25 16:03 Rick-Methot-NOAA

There are some instructions here on stack exchange for how to add old releases to a repository. It would be nice if they were all in ss3-source-code rather than just the newer ones being there. We have a Google Drive with many of the executables, which is where I got the ones that Kath was wanting.

kellijohnson-NOAA avatar Mar 24 '25 16:03 kellijohnson-NOAA

For posterity, I just found the folders with SYNA.FOR and SYNL.FOR files from 1994. These are the models developed for hake and sablefish, respectively. They have been gathering electronic dust on my hard drive for 31 years.

Rick-Methot-NOAA avatar Mar 24 '25 17:03 Rick-Methot-NOAA

Given the two separate recent requests for old executables, I think adding more to github makes sense. The Google Drive folder (only available to NOAA folks right now (https://drive.google.com/drive/folders/1_yadb9qGhIQXdD1LAVKt0smYmW-NUiou) has 63 executables. We should probably at least filter for the most recent bug-fix version within each version (e.g. 3.30.15.09, but not 3.30.15.03 and 3.30.15.00 which are in that set). We might also consider only posting 1 or 2 of the 3.24 releases, if any.

Lastly, there's something to be said for folks getting in touch if they're working with really old SS3 versions, but for posterity, it's good to have them public anyway.

iantaylor-NOAA avatar Mar 24 '25 17:03 iantaylor-NOAA

@kellijohnson-NOAA Yeah I was trying to figure out how to have releases without have a commit or like a real tag with it since we don't have git committed versions on GitHub prior to v3.30.17.. In what you posted it still seems like you need to have a commit that can be associated with that release.

e-perl-NOAA avatar Mar 24 '25 18:03 e-perl-NOAA

My suggestion would be to just use some of the most earliest commits in the repo even though they aren't necessarily associated with the code for that release.

kellijohnson-NOAA avatar Mar 24 '25 18:03 kellijohnson-NOAA