Replies: 2 comments
-
To start, we redesigned this as the |
Beta Was this translation helpful? Give feedback.
-
@amckinney design question around |
Beta Was this translation helpful? Give feedback.
-
To start, we redesigned this as the |
Beta Was this translation helpful? Give feedback.
-
@amckinney design question around |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Overview
We're beginning to design a CLI command that users can run to:
CHANGELOG.md
entry outlining a human-readable representation of the API changes.Discoverability
All of these commands boil down to managing and working with API changes. We want these commands to be discoverable (i.e. what do I see when I run
fern --help
), but we also want to consolidate these operations under a common umbrella.We have plans for a CLI hierarchy overhaul in the CLI's first major version (i.e.
1.0.0
), so we aim to design these new commands in a way that mirrors the new model.Commands
We propose the following set of commands all under the new
sdk
subcommand:fern sdk changelog --from <from> [--from-version <version>] [--output={filepath,json,text,version}]
fern sdk version --from <from> [--from-version <version>]
--output version
flag using the command above.Note that the same
--api
filter will be available for users that have multi-api repository setups. The--from-version
flag is marked as optional to start because the CLI can (eventually) determine the current version for a given SDK on its own.Examples
# Generate the next semantic version. $ fern sdk changelog --api default --from bac7962 --from-version 1.0.0 --output version 2.0.0
# Generate the next semantic version. $ fern sdk version --api default --from bac7962 --from-version 1.0.0 2.0.0
Beta Was this translation helpful? Give feedback.
All reactions