View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0009441 | Taler | documentation | public | 2025-01-07 12:24 | 2026-03-20 23:55 |
| Reporter | oec | Assigned To | Christian Grothoff | 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 | high | Severity | text | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Product Version | git (master) | ||||
| Target Version | 1.5 | Fixed in Version | 1.5 | ||
| Summary | 0009441: Protocol version missing in public documentation | ||||
| Description | The public documentation at docs.taler.net, and there under "Core Protocol Specification", none of the protocol API's (exchange, merchant, auditor etc.) mention their current version of their protocol. I suggest that for each API, the protocol version should be - part of the "Overview" section - prominently and consistently presented in the introduction of each API - (if possible) automatically synchronized with the versions set in the main branches of the respective API repos | ||||
| Tags | No tags attached. | ||||
| related to | 0009388 | closed | Christian Grothoff | Add semver information to REST-API endpoints |
| Eh, they all do mention this under /config. I'm not against moving this up or making it more prominent, but it is not *missing*. | |
| As far as automatic sync goes, that should *not* be done, as we _do_ sometimes write specs before implementation, and/or may have an implementation in a branch but the spec already in master, etc. | |
| 5875b7ec..63b675a7 adds version documentation to each of the APIs at the very top in a new "Protocol version" section. Note that we do NOT use semver, we use libtool-style versioning for protocols (with ranges). So to see the range, you need to look at "@since" and possibly "@deprecated" annotations to see which range of protocols a particular field or endpoint is supported for. | |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2025-01-07 12:24 | oec | New Issue | |
| 2025-01-07 12:24 | oec | Status | new => assigned |
| 2025-01-07 12:24 | oec | Assigned To | => Christian Grothoff |
| 2025-01-07 21:34 | Christian Grothoff | Note Added: 0023945 | |
| 2025-01-07 21:35 | Christian Grothoff | Note Added: 0023946 | |
| 2025-01-07 21:35 | Christian Grothoff | Assigned To | Christian Grothoff => |
| 2025-01-07 21:35 | Christian Grothoff | Severity | feature => text |
| 2025-01-07 21:35 | Christian Grothoff | Status | assigned => implementing |
| 2025-01-11 11:17 | Christian Grothoff | Target Version | 1.0 => 1.0 stretch goals |
| 2025-04-17 19:11 | Christian Grothoff | Target Version | 1.0 stretch goals => post-1.0 |
| 2026-02-07 21:44 | Christian Grothoff | Priority | normal => high |
| 2026-02-07 21:44 | Christian Grothoff | Assigned To | => Christian Grothoff |
| 2026-02-07 21:44 | Christian Grothoff | Status | implementing => assigned |
| 2026-02-07 21:44 | Christian Grothoff | Status | assigned => implementing |
| 2026-02-07 21:45 | Christian Grothoff | Relationship added | related to 0009388 |
| 2026-02-27 21:24 | Christian Grothoff | Note Added: 0027934 | |
| 2026-02-27 21:25 | Christian Grothoff | Status | implementing => informing |
| 2026-02-27 21:25 | Christian Grothoff | Resolution | open => fixed |
| 2026-02-27 21:25 | Christian Grothoff | Fixed in Version | => 1.5 |
| 2026-02-27 21:25 | Christian Grothoff | Target Version | post-1.0 => 1.5 |
| 2026-03-20 23:55 | Christian Grothoff | Status | informing => closed |