View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0007990 | Taler | wallet-core | public | 2023-11-21 20:13 | 2024-03-07 19:49 |
| Reporter | MarcS | Assigned To | Florian Dold | Resolution deadline | |
| Implementer | Reviewer | ||||
| Release signed by | Deployed by | ||||
| Verifier | Communicator | ||||
| Data protection authority notification required | No | ||||
| CSIRT notification required | No | ||||
| Estimated effort (hours) | Actual effort (hours) | 0 | |||
| Fast-track | No | ||||
| Work package | none | ||||
| Priority | normal | Severity | feature | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Product Version | 0.9.3 | ||||
| Target Version | 0.9.4 | Fixed in Version | 0.9.4 | ||
| Summary | 0007990: versionInfo always returns 1.0.0 | ||||
| Description | ["versionInfo": ["bank": "0:0:0", "devMode": false, "version": "1:0:0", "exchange": "17:0:0", "merchant": "5:0:1"]] Wallet-core should return useful information in the "version" field, not just 1:0:0, and also NOT just 0:9:3, but add enough data that we can ask users to tell us which version the app shows them to know exactly which git commit this was built of. We could add another field named "git" with the commit, which is only shown to the user when they tap on the version number. Then we can have both, a clean version to show like 0:9:3 (btw, why colons instead of dots?), and the git commit accessible if needed. That means, that the build process "make embedded" must find out the git commit somehow, and insert it into the taler-wallet-core-qjs.mjs it builds... "bank" probably also shouldn't show 0:0:0... And "devMode" is deprecated, get rid of that. | ||||
| Tags | No tags attached. | ||||
| Indeed the bank version is not correct. However, I think there is a confusion about the semantics of the version numbers. These are *protocol version ranges* (see https://docs.taler.net/taler-developer-manual.html#versioning). These do not correspond to the semver of the component implementation. The number is purely about the *API* (i.e. 2:0:2 means API versions 0, 1 and 2 are supported), while the component semvers are about the implementation (0.9.3 etc.) | |
| At launch, the very first call 'init' returns e.g. ["versionInfo": ["version": "1:0:0", "exchange": "17:0:0", "merchant": "5:0:1", "bank": "1:0:0"]] export interface WalletCoreVersion { version: string; exchange: string; merchant: string; bank: string; } 1) These are NOT semver versions, but protocol versions. While it's absolutely fine to return them in 'init' so the app can print them in the logfile, they are pretty useless to the app user. 2) GetVersionOp returns exactly the same values we already printed to the log. FEATURE REQUEST: GetVersionOp should instead return the semver of the wallet-core component implementation - including the latest git commit of wallet-core. That means, that the build process "make embedded" must find out the git commit somehow, and insert it into the taler-wallet-core-qjs.mjs it builds... | |
| I'm not against *additionally* returning the release semver, but this is a feature request, post-1.0. | |
| As multiple people have now asked me for it, I've implemented it: fdold-work@sapota ~/r/t/wallet-core (master)> taler-wallet-cli api 'getVersion' '{}' { "type": "response", "operation": "getVersion", "id": "my-req", "result": { "implementationSemver": "0.9.4-dev.8", "implementationGitHash": "7e7306ec4585c5fd7a2ceb727177e7d249ae6031", "version": "3:0:2", "exchange": "17:0:0", "merchant": "5:0:1", "bankConversionApiRange": "2:0:0", "bankIntegrationApiRange": "1:0:0", "corebankApiRange": "2:0:0", "bank": "1:0:0", "devMode": false } } | |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2023-11-21 20:13 | MarcS | New Issue | |
| 2023-11-21 20:13 | MarcS | Status | new => assigned |
| 2023-11-21 20:13 | MarcS | Assigned To | => Florian Dold |
| 2023-12-13 07:34 | Florian Dold | Status | assigned => informing |
| 2023-12-13 07:34 | Florian Dold | Resolution | open => fixed |
| 2023-12-13 07:34 | Florian Dold | Note Added: 0020749 | |
| 2023-12-16 15:15 | MarcS | Status | informing => feedback |
| 2023-12-16 15:15 | MarcS | Resolution | fixed => reopened |
| 2023-12-16 15:15 | MarcS | Note Added: 0020767 | |
| 2023-12-22 13:54 | Christian Grothoff | Note Added: 0020792 | |
| 2023-12-22 13:55 | Christian Grothoff | Severity | minor => feature |
| 2023-12-22 13:55 | Christian Grothoff | Target Version | 0.9.4 => post-1.0 |
| 2024-01-23 21:34 | Florian Dold | Status | feedback => informing |
| 2024-01-23 21:34 | Florian Dold | Resolution | reopened => fixed |
| 2024-01-23 21:34 | Florian Dold | Note Added: 0021008 | |
| 2024-01-27 00:13 | Christian Grothoff | Fixed in Version | => 0.9.4 |
| 2024-01-27 00:13 | Christian Grothoff | Target Version | post-1.0 => 0.9.4 |
| 2024-03-07 19:49 | Christian Grothoff | Status | informing => closed |