ADR-4 Default eras for CLI commands #25
Conversation
newhoggy
force-pushed
the
newhoggy/adr-5-default-eras-for-cli-commands
branch
from
7e6da36
to
aeb0dc3
Compare
newhoggy
changed the title
newhoggy
force-pushed
the
newhoggy/adr-5-default-eras-for-cli-commands
branch
from
aeb0dc3
to
bd64966
Compare
|
|
||
| 📜 Proposed 2023-09-04 | ||
|
|
||
| # Context |
There was a problem hiding this comment.
There is too much spacing of paragraphs, it's a bit hard to read. Some paragraphs should be joined together.
Suggestion: use one sentence per line in markdown - it makes smaller git diffs.
|
|
||
| This was the context from the adoption of [[ADR-1 Default eras for CLI commands]] until now. | ||
|
|
||
| Going foward we have additional concerns to consider: |
There was a problem hiding this comment.
Unnecessary colon at the end of paragraph.
|
|
||
| # Decision | ||
|
|
||
| There will be no "default" era. Instead, two era selectors will be included with the CLI: |
There was a problem hiding this comment.
Can you provide commands examples for each of selectors?
|
|
||
| # Decision | ||
|
|
||
| There will be no "default" era. Instead, two era selectors will be included with the CLI: |
There was a problem hiding this comment.
Does it mean that there will be only three eras available to select? What If I start a testnet in babbage, and I'd like to execute commands in babbage. These new era selectors will not allow for that.
|
|
||
| There will be no "default" era. Instead, two era selectors will be included with the CLI: | ||
|
|
||
| * `local` - This era is the latest hard-coded era supported by `cardano-cli` at the time `cardano-cli` was released. This will not change in the event of a |
There was a problem hiding this comment.
Tbf I prefer latest to local. local is not clear to me in the era context.
There was a problem hiding this comment.
But latest can be ambiguous right? In case of a hard fork, users could expect that latest is the newest fork.
What about hardcoded?
| era unless explicitly instructed not to. `cardano-cli` maybe be instructed to fail on an era-mismatch with the network era or use some other | ||
| strategy if the need arises to have further strategies. | ||
|
|
||
| * `network` - This era is the era of the network the run of the command is intended for. In order to acquire the era, `cardano-cli` must connect to the node |
There was a problem hiding this comment.
Are selectors local and network supposed to be used as:
cardano-cli local transaction build-raw
cardano-cli network transaction build
?
If yes, those seem to be super misleading. If those are era selectors, names should relate to eras somehow, for example era-local or era-network should be used instead.
If we would like to keep the names as they are, they shouldn't be called era selectors, or rather something like "locality selectors" (feel free to pick a better name). That would mean that some commands are meant to be used online, and some offline and the era aspect should get abstracted away from the end user.
There was a problem hiding this comment.
Is there a command to query what network resolves to? Such a command could help users check - for example in their CI - that network has the value they expect. And if not, their CI will break and they are notified they need to do something.
| * The possibility of a hard fork means tradeoffs are necessary with selecting eras. | ||
| There is continues to be a risk that users get surprises after a hard fork. Providing `local` and `network` selectors will just mean that users will get | ||
| choose what kind of surprises they may get. |
There was a problem hiding this comment.
| * The possibility of a hard fork means tradeoffs are necessary with selecting eras. | |
| There is continues to be a risk that users get surprises after a hard fork. Providing `local` and `network` selectors will just mean that users will get | |
| choose what kind of surprises they may get. | |
| * The possibility of a hard fork means tradeoffs are necessary with selecting eras. | |
| There continues to be a risk that users get surprised after a hard fork. Providing `local` and `network` selectors will just mean that users will get to | |
| choose what kind of surprises they may get. |
Can you rewrite this point, it's unclear what surprises are meant here?
| * The possibility of a hard fork means tradeoffs are necessary with selecting eras. | ||
| There is continues to be a risk that users get surprises after a hard fork. Providing `local` and `network` selectors will just mean that users will get | ||
| choose what kind of surprises they may get. | ||
| * Third party tools will need to consider how to code around an impending hard fork boundary by being aware of what changes are coming and code defensively, |
There was a problem hiding this comment.
Can you add a supporting example what would be a hard-fork-tolerant usage?
| There is continues to be a risk that users get surprises after a hard fork. Providing `local` and `network` selectors will just mean that users will get | ||
| choose what kind of surprises they may get. | ||
| * Third party tools will need to consider how to code around an impending hard fork boundary by being aware of what changes are coming and code defensively, | ||
| choosing the appropriate era selector with the behaviour they need to implement their features in a hard-fork tolerant manner. |
There was a problem hiding this comment.
| choosing the appropriate era selector with the behaviour they need to implement their features in a hard-fork tolerant manner. | |
| choosing the appropriate era selector with the behaviour they need to implement their features in a hard-fork-tolerant manner. |
| choose what kind of surprises they may get. | ||
| * Third party tools will need to consider how to code around an impending hard fork boundary by being aware of what changes are coming and code defensively, | ||
| choosing the appropriate era selector with the behaviour they need to implement their features in a hard-fork tolerant manner. | ||
| * Users may or may not necessarily be using the current era by default depending on their choices. |
| * Third party tools will need to consider how to code around an impending hard fork boundary by being aware of what changes are coming and code defensively, | ||
| choosing the appropriate era selector with the behaviour they need to implement their features in a hard-fork tolerant manner. | ||
| * Users may or may not necessarily be using the current era by default depending on their choices. | ||
| * No default era imposes on the user the burden of either choosing an era or an era selector. |
There was a problem hiding this comment.
The discussion how era selectors change usage of choosing eras is missing.
| choosing the appropriate era selector with the behaviour they need to implement their features in a hard-fork tolerant manner. | ||
| * Users may or may not necessarily be using the current era by default depending on their choices. | ||
| * No default era imposes on the user the burden of either choosing an era or an era selector. | ||
| * The decision to have a default era is postponed so we're less likely to make the wrong choice. |
There was a problem hiding this comment.
How so? local would mean hardcoded default era, do I get this right?
|
|
||
| Historically we changed the default transactions era in the first release after the hard fork in order to give the tool/dapp developers the possibility to update the default transaction era in their code after the hard fork - otherwise their tools would stop working after the hard fork. | ||
|
|
||
| Care needs to be taken to avoid making a CLI release that does not work by default by defaulting to using an era that is not yet active. So that's why we have historically only updated the default era in the release after the hard fork, not the release before. |
There was a problem hiding this comment.
| Care needs to be taken to avoid making a CLI release that does not work by default by defaulting to using an era that is not yet active. So that's why we have historically only updated the default era in the release after the hard fork, not the release before. | |
| Care needs to be taken to avoid making a CLI release that does not work by defaulting to using an era that is not yet active. So that's why we have historically only updated the default era in the release after the hard fork, not the release before. |
I get what you meant, but I think this can be simplified without losing semantics.
|
|
||
| This is also true for transactions upgraded from an older era, although to a lesser extent. | ||
|
|
||
| Constructing a command in the currently era is the for any command that requires protocol-parametes is the only way to guarantee a transaction works as intended. |
There was a problem hiding this comment.
This reads weird 🙁 Maybe a mash-up of two different versions of the sentence?
|
|
||
| There will be no "default" era. Instead, two era selectors will be included with the CLI: | ||
|
|
||
| * `local` - This era is the latest hard-coded era supported by `cardano-cli` at the time `cardano-cli` was released. This will not change in the event of a |
There was a problem hiding this comment.
But latest can be ambiguous right? In case of a hard fork, users could expect that latest is the newest fork.
What about hardcoded?
| era unless explicitly instructed not to. `cardano-cli` maybe be instructed to fail on an era-mismatch with the network era or use some other | ||
| strategy if the need arises to have further strategies. | ||
|
|
||
| * `network` - This era is the era of the network the run of the command is intended for. In order to acquire the era, `cardano-cli` must connect to the node |
There was a problem hiding this comment.
Is there a command to query what network resolves to? Such a command could help users check - for example in their CI - that network has the value they expect. And if not, their CI will break and they are notified they need to do something.
Please see ADR-0 Architecture Decision Records for information about what ADRs are in general.
Rendered