Paths

Table of Contentst

Differential D15275

[Cashtab] Display Cashtab webapp version on settings page if available
ClosedPublic
Actions

Authored by bytesofman on Jan 25 2024, 00:48.

Details

Reviewers

Fabien

Group Reviewers

Restricted Project

Commits

rABCaea436e0c6f0: [Cashtab] Display Cashtab webapp version on settings page if available

Summary

Display Cashtab version on settings page.

This way we can tell what version a user is getting on their device if they are experiencing an issue, and confirm whether or not the issue is related to having a cached version.

Note: we want the version from package.json, and not package-lock.json, as the version number in package-lock.json only changes to match package.json when the dependencies change. So, the version in package-lock.json is the last version where the dependencies changed, not necessarily the most recent version.

Will prob want some kind of a lint strategy for this soon, but will see how it works manually. The type of version bump for now is the kind of thing that should be reviewed. This is an improvement over no version mgmt.

Test Plan

npm start

Navigate to Configure.js and observe the version at the bottom of page

Diff Detail

Repository

rABC Bitcoin ABC

Lint

Lint Not Applicable

Unit

Tests Not Applicable

Event Timeline

bytesofman created this revision.Jan 25 2024, 00:48

Herald added a reviewer: Restricted Project. · View Herald TranscriptJan 25 2024, 00:48

bytesofman edited the test plan for this revision. (Show Details)Jan 25 2024, 00:50

Harbormaster completed remote builds in B26638: Diff 44567.Jan 25 2024, 00:51

if hash is not available as env var

if hash is available

bytesofman published this revision for review.Jan 25 2024, 00:52

bytesofman edited the test plan for this revision. (Show Details)

bytesofman edited the summary of this revision. (Show Details)

Why don't you use the version from package.lock instead ? this is more user friendly than a commit hash and it works when deployed in a container

In D15275#343388, @Fabien wrote:

Why don't you use the version from package.lock instead ? this is more user friendly than a commit hash and it works when deployed in a container

Need some more thought to implement traditional semver in the Cashtab webapp.

I haven't been actively bumping this version for Cashtab webapp (as I have for the extension, which is easier to have milestones for since it must be submitted to an app store).

To maintain the webapp version number, will need some kind of linter to make sure it is changed on every diff, or changed only once on every stacked diff. Cashtab often has many diffs open and green at the same time. So each rebase would also change this.

If it's totally automated, some versions that are not patches may be marked as such, or vice versa. I'm not sure it's practical to maintain this -- could be more trouble than its worth.

Maybe simple enough to automate it so that every landed diff bumps a patch version, then we only need to worry about bumping the feature number manually. But a good % of cashtab diffs should be bumping the middle number.

Commit hash gives us the exact diff the user is on, which is what we need to troubleshoot issues / identify if the user is getting the latest version or not.

imo it's worth landing this first. I'm not sure if maintaining semver will be worth it, and this does improve current behavior.

In D15275#343494, @bytesofman wrote:

In D15275#343388, @Fabien wrote:

Why don't you use the version from package.lock instead ? this is more user friendly than a commit hash and it works when deployed in a container

Need some more thought to implement traditional semver in the Cashtab webapp.

I haven't been actively bumping this version for Cashtab webapp (as I have for the extension, which is easier to have milestones for since it must be submitted to an app store).

To maintain the webapp version number, will need some kind of linter to make sure it is changed on every diff, or changed only once on every stacked diff. Cashtab often has many diffs open and green at the same time. So each rebase would also change this.

If it's totally automated, some versions that are not patches may be marked as such, or vice versa. I'm not sure it's practical to maintain this -- could be more trouble than its worth.

Maybe simple enough to automate it so that every landed diff bumps a patch version, then we only need to worry about bumping the feature number manually. But a good % of cashtab diffs should be bumping the middle number.

Commit hash gives us the exact diff the user is on, which is what we need to troubleshoot issues / identify if the user is getting the latest version or not.

imo it's worth landing this first. I'm not sure if maintaining semver will be worth it, and this does improve current behavior.

OK with the rationale, but still it doesn't work in production where there is no git repository.

In D15275#343498, @Fabien wrote:

In D15275#343494, @bytesofman wrote:

In D15275#343388, @Fabien wrote:

Why don't you use the version from package.lock instead ? this is more user friendly than a commit hash and it works when deployed in a container

Need some more thought to implement traditional semver in the Cashtab webapp.

I haven't been actively bumping this version for Cashtab webapp (as I have for the extension, which is easier to have milestones for since it must be submitted to an app store).

To maintain the webapp version number, will need some kind of linter to make sure it is changed on every diff, or changed only once on every stacked diff. Cashtab often has many diffs open and green at the same time. So each rebase would also change this.

If it's totally automated, some versions that are not patches may be marked as such, or vice versa. I'm not sure it's practical to maintain this -- could be more trouble than its worth.

Maybe simple enough to automate it so that every landed diff bumps a patch version, then we only need to worry about bumping the feature number manually. But a good % of cashtab diffs should be bumping the middle number.

Commit hash gives us the exact diff the user is on, which is what we need to troubleshoot issues / identify if the user is getting the latest version or not.

imo it's worth landing this first. I'm not sure if maintaining semver will be worth it, and this does improve current behavior.

OK with the rationale, but still it doesn't work in production where there is no git repository.

lol ok well this bumps the priority for figuring out semver, will check it out

bytesofman retitled this revision from [Cashtab] Display hash of git commit current version on settings page if available to [Cashtab] Display Cashtab webapp version on settings page if available.Jan 25 2024, 17:23

bytesofman edited the summary of this revision. (Show Details)

bytesofman edited the test plan for this revision. (Show Details)

get version from package.json

bytesofman edited the summary of this revision. (Show Details)Jan 25 2024, 17:24

Harbormaster completed remote builds in B26656: Diff 44594.Jan 25 2024, 17:30

Fabien accepted this revision.Jan 25 2024, 17:57

Fabien added inline comments.