Inconsistent formatting of filename and folder names between DigiByte Core releases

[saltedlolly]

[UPDATE: I have rewritten this explanation, after digging deeper into the issue.]

I am in the process of updating DigiNode Tools so that you can optionally switch between the DigiByte Core release version and the pre-release version (if available). This will make it easy for DigiNode users to quickly install/upgrade to the pre-release version with minimal effort, and even revert back to the release version in the event of a problem.

I have the changes to my script pretty much finished, except that I have noticed an inconsistency with the formatting of the release filename for 8.22.0-rc2, which is breaking my script.

Currently in my script the download URL is formatted like this: https://github.com/DigiByte-Core/digibyte/releases/download/v${DGB_VER_RELEASE}/digibyte-${DGB_VER_RELEASE}-${ARCH}-linux-gnu.tar.gz

It inserts the relevant variables as needed:
DGB_VER_RELEASE=digibyte_core_release_version_number e.g. 7.17.3 or 8.22.0-rc1
ARCH=system_architecture e.g. aarch64

This works fine for 7.17.2, 7.17.3 and 8.22.0-rc1:

https://github.com/DigiByte-Core/digibyte/releases/download/v7.17.2/digibyte-7.17.2-aarch64-linux-gnu.tar.gz
https://github.com/DigiByte-Core/digibyte/releases/download/v7.17.3/digibyte-7.17.3-aarch64-linux-gnu.tar.gz
https://github.com/DigiByte-Core/digibyte/releases/download/v8.22.0-rc1/digibyte-8.22-rc1-aarch64-linux-gnu.tar.gz

Unfortunately it breaks on 8.22.0-rc2:

https://github.com/DigiByte-Core/digibyte/releases/download/v8.22.0-rc2/DigiByte-v8.22.0-RC2-aarch64-linux-gnu.tar.gz

With 8.22.0-rc2, the filename now has a letter 'v' before the version number (not to mention the capitalisation in 'DigiByte'). This means my script is not able to correctly generate the correct URL and the download fails.

Obviously, for DigiNode Tools to be able to automatically download all future releases of DigiByte Core automatically, it helps if the formatting of the filename is consistent across all releases. If this is a one off mistake, that's fine - I can obviously handle the discrepancy on this occasion by tweaking the download URL for 8.22.0-rc2 but if not, I think it is really important to ensure there is consistency. It affects anyone who is trying to download DigiByte automatically using bash scripts etc.

[saltedlolly]

I've been writing workarounds for 8.22.0-rc2 for DigiNode Tools and I noticed another inconsistency between this release and the others. When you extract the downloaded tar file for linux, the folder it extracts into is called "digibyte-af42429717ac" rather than the convention of "digibyte-8.22.0-rc2" used by all prior releases/prereleases.

@JaredTate Based on the release notes, I believe you put out the RC2 pre-release. Is that correct? For future releases, would it be possible to stick to a consistent filname structure, and download folder name? I admit I don't really know how the release process works, but it would be really helpful for me, and anyone else trying to access current and future releases/prereleases programmatically, if there was consistency in the formatting of file and folder names.

So for example, if we decide to keep consistent with the file and folder names used in all releases prior to 8.22.0-rc2, then a future 8.22.0-rc3 pre-release would have the filename structure:

digibyte-8.22.0-rc3-aarch64-linux-gnu.tar.gz [ i.e. no letter v before the version number ]

The extracted folder name would be called 'digibyte-8.22.0-rc3'

Similarly, the future 8.22 official release would be: digibyte-8.22.0-aarch64-linux-gnu.tar.gz

And the extracted folder name: digibyte-8.22.0

[saltedlolly]

I have also discovered that 8.22.0-rc2 is self-reporting its version number to be simply "8.22.0". Is that normal? Should it not be using "8.22.0-rc2"? Is it normal for a release candidate to simply use the version of the final release?

(This causes issues in DigiNode Tools since it is difficult to know exactly which local version of DigiByte Core is currently running.)

@SmartArray Is this usually set from the GUIX build scripts?

[ghost]

A release candidate (RC) is a beta version with the potential to be a stable product, which is ready to release unless significant bugs emerge.

Maybe use sha1sum/md5sum in your script.

[saltedlolly]

@Jongjan88 Thanks. I'm aware of that but I wasn't sure whether typically the version number is changed in the RC, as the only difference between that and the final release.

I think in this case, once a pre-release version is downloaded and installed I can simply store the release version number as the local version number in the diginode.settings file that stores all local variables. This way I should never have to query the running DigiByte Core itself for its version number (at least for pre-releases). That might be simpler that sha1sum/md5sum in this case.

As for the file and folder name, it would be good if these were formatted consistently across releases, as I mentioned above.

[saltedlolly]

I am querying Github for the latest pre-release version using:

DGB_VER_PRERELEASE=$(jq -r 'map(select(.prerelease)) | first | .tag_name' <<< $(curl --silent https://api.github.com/repos/digibyte-core/digibyte/releases) | sed 's/v//g')

(This returns 'null' if no pre-release is currently available, or the version number of the latest pre-release e.g. "8.22.0-rc2")

To query the latest release version from Github, I am using:

DGB_VER_RELEASE=$(curl -sfL https://api.github.com/repos/digibyte-core/digibyte/releases/latest | jq -r ".tag_name" | sed 's/v//g')

(This returns the version number of the latest release e.g. "7.17.3")

[JaredTate]

I am all for standardizing it & being consistent. Whatever ya'll think works best and is clean, we should stick to it. We may need a version bump for the next rc. The issue is the version is set in many different files for different binaries & platforms in the title. We need a checklist of all the files to change before a version bump release to be consistent.

configure.ac in the main directory is where version is set that most builders reference. And you are right, we need to change the rc version as it reads 0. Good catch. Tagging @ycagel @gto90

digibyte/configure.ac

Lines 2 to 5 in b75fea6

	define(_CLIENT_VERSION_MAJOR, 8)
	define(_CLIENT_VERSION_MINOR, 22)
	define(_CLIENT_VERSION_BUILD, 0)
	define(_CLIENT_VERSION_RC, 0)

[saltedlolly]

@JaredTate Thanks. I see we need to update the RC number in that file. Can you tell me where the folder name is set e.g. digibyte-7.17.3 or digibyte-8.22.0-rc3

Where does the GUIX build tool fit into this? Are some of these settings set in that?

It would also be helpful to understand why digibyte-8.22.0-rc2 deviated from the conventions used in all prior releases. Was something changed? What do we need to do to standardize this for the future?

[JaredTate]

I think we can drop the "v" on all future releases. So we moved from gitian building to guix building. The gitian files had a version name in each os, but not guix. It actually was manually added to binary releases, so we should standardize the format. I will open a pr for this.

[saltedlolly]

Could we please update the .tar.gz filenames for the 8.22.0-rc4 release like we did for rc3:

For every .tar.gz filename we need to replace "527219d69dd9" with "8.22.0-rc4". The version string is not getting added to the files automatically as it should be, instead inserting this random string (527219d).

so digibyte-527219d69dd9-aarch64-linux-gnu.tar.gz becomes digibyte-8.22.0-rc4-aarch64-linux-gnu.tar.gz etc.

Without this change, it is really difficult to locate the download URL in DigiNode Tools and requires a lot of work to get around it. Renaming the files is a simple workaround taking a minute or two. @Jongjan88 has said he plans to try and fix this for the final release so for now it would be a great help if we could change it manually. Once that happens I can push RC4 out to all the DigiNode users. Thanks.

[saltedlolly]

You can see how Bitcoin Core inserts the version number into the filename here: https://bitcoincore.org/bin/bitcoin-core-26.1/

[JaredTate]

As I mentioned in response to you before here: #217 (comment)

The release needs to be fully signed for the commit hash to disappear with GUIX. The commit hash needs to be there for the signing process to work as first part of the process. Removing the commit hash from the GUIX build process is totally irrational and will not work. Why break something that works fine as is.

Leaving the commit hash makes it easier for people to help verify the build commit for unsigned binaries. I was going to make a video explaining this.

Why should we alter the GUIX build process and make it harder for people to verify binaries? It would be simple to code something for digi node tools service that gets a commit hash and adds it to name. Jus reference the latest git tag and commit hash. Easy with the github API.

Also, 7.17.3 was built with gitian build process. 8.22 is now built with GUIX. So two different build processes.

[saltedlolly]

Jared I don't want to argue you with about this. I just want to get RC4 into the hands of DigiByte testers. It would take maybe 2 minute to rename the .tar.gz files on GitHub. To rewrite DigiNode Tools to try and look up the file names of the release to then generate the url to download them would likely take several hours of work, all for a temporary workaround. I really don't want to have to do that. If you are willing to rename them like we did for RC3 then I can get RC4 out to the community immediately. If not, it's unlikely to happen. I'm asking for you to please accommodate this change on this occasion so we can get more people testing RC4. Many thanks.

[saltedlolly]

Once again we have this same issue with v8 final. Is it really that hard to get this right the first time? Can we please fix the filenames of the v8 final release so that they are consistent with the naming conventions that have come before?

[saltedlolly]

The filenames should be digibyte-8.22.0-aarch64-linux-gnu.tar.gz etc. (i.e. include the version number in the filename.)

Please can we fix this? I am in the process of updating DigiNode Tools to be able to install the final v8 release but I can't do this until the naming issue has been resolved.

cc @ycagel @gto90 @JaredTate