-
-
Notifications
You must be signed in to change notification settings - Fork 116
2022 10 24 API version parameter
- Status: accepted
- Date: 2022-10-24
Technical Story: #362
{Describe the context and problem statement, e.g., in free form using two to three sentences. You may want to articulate the problem in form of a question.}
The application should be able to deduce the API version to used based on the sfdx-project.json
file as well.
- CLI Experience
- Compatibility with existing behaviour>
- Use parameter or use
sfdx-project.json
or use latest (in that order) - Use a new parameter to search in
sfdx-project.json
- Use a keyword in
-a
parameter to tell the system to look insfdx-project.json
Chosen option: "Use parameter or use sfdx-project.json
or use latest (in that order)", because it has maximum compatibility with existing behavior and does not require huge changes in CLI usage.
- Now when
-a
not set we use the same API value as the one fromsfdx-project.json
. Incremental package generation is done with the same API version used for deployment
- It may use
sfdx-project.json
instead of latest when you don't specify-a
. You may be used to have latest version used in this case.
If the parameter is set then use parameter
Else try to extract sourceApiVersion
from sfdx-project.json
Then if the API version is not defined or not supported, use the latest.
- Good, Same CLI experience as before
- Good, Use what it can find, in order
- Bad, May be relaying on latest with an old version in
sfdx-project.json
If the new parameter is filled then use it. Or latest if version not supported
- Good, new parameter, does not touch previous parameter
- Bad, 2 parameters for the same aspect
Use -a
with a keyword (file) to drive the cli to search in sfdx-project.json
for the API version
Or latest if version not supported
- Good, reuse the
-a
- Good, does not behave differently when not setting
-a
- Bad, create a convention in the version parameter