inconsistent semantics of rev -1 #4
Description
From what I observed an api revision of -1 has different semantics in get and deploy:
in apis get a revision of -1 is ignored and all available revisions are listed
apigeecli apis get --name apigeecli-test --token $TOKEN --org $APIGEE_ORG -v -1
{
"metaData": {
"createdAt": "1651819458727",
"lastModifiedAt": "1651822831234",
"subType": "Proxy"
},
"name": "apigeecli-test",
"revision": [
"1",
"2"
],
"apiProxyType": "PROGRAMMABLE"
}In apigeecli apis deploy a revision of -1 leads to an error:
apigeecli apis deploy --name apigeecli-test --env test1 --token $TOKEN --org $APIGEE_ORG -v -1
httpclient.go:349: status code 400, error in response: {
"error": {
"code": 400,
"message": "invalid deployment name \"organizations/APIGEE_ORG/environments/test1/apis/apigeecli-test/revisions/-1\": \"-1\" is an invalid API Proxy Revision ID",
"status": "INVALID_ARGUMENT",
"details": [
{
"@type": "type.googleapis.com/google.rpc.RequestInfo",
"requestId": ""
}
]
}
}The default value of -1 is also commonly used as a list index shortcut for the last element. What do you think if we could use -1 to refer to the latest revision? (use a get, sort revisions descending, use the highest as a revision param for the deployment)
Otherwise I think the -1 default value has very limited utility in the deploy command and is misleading.