Closed Bug 1460019 Opened 7 years ago Closed 6 years ago

Include a version in api.json

Categories

(Taskcluster :: Services, enhancement, P5)

enhancement

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: dustin, Assigned: jhford)

References

Details

Attachments

(2 files, 3 obsolete files)

For the moment we will assume version: 0 to mean version: 'v1', but let's change it so we don't need to do that translation.
At the same time, let's change the API `name` proeprty to the more descriptive `serviceName`.
See Also: → 1430096
Update: version is the version of the reference format; not the version of the API. So maybe add an apiVersion field.
Blocks: 1461815
Summary: Change `version` in references to be of the form `v1` → Include a version in api.json
Note that this is needed in both exchanges and API definitions
We'll also want to remove baseUrl from the reference format.
Assignee: bstack → dustin
Once https://github.com/taskcluster/taskcluster-references/pull/4 lands we can add a new version with this information.
This is the patch required to get api version into the api references
Assignee: dustin → jhford
Status: NEW → ASSIGNED
Attachment #9009115 - Flags: review?(dustin)
Attached patch taskcluster-references patch (obsolete) — Splinter Review
This is the patch that I believe should add the apiVersion field to the lib-api schema. It's not clear to me why the schema for lib-api isn't stored in lib-api and published like we do for other schemas on deployment, what's the reason for this decision?
Attachment #9009117 - Flags: review?(dustin)
Attachment #9009117 - Flags: review?(dustin)
Attachment #9009115 - Flags: review?(dustin)
Comment on attachment 9009115 [details] [diff] [review] taskcluster-lib-api patch to include api version Review of attachment 9009115 [details] [diff] [review]: ----------------------------------------------------------------- ::: package.json @@ +1,3 @@ > { > "name": "taskcluster-lib-api", > + "version": "12.5.0", This typically gets bumped in a commit of its own, so it's easy to spot and has a tag on that revision. ::: src/builder.js @@ +181,4 @@ > reference() { > const reference = { > version: 0, > + apiVersion: this.version, Note that this is not an integer :)
Attachment #9009117 - Flags: review?(dustin)
Attachment #9009115 - Flags: review?(dustin)
Attachment #9009115 - Attachment is obsolete: true
Attachment #9009115 - Flags: review?(dustin)
Comment on attachment 9009117 [details] [diff] [review] taskcluster-references patch Review of attachment 9009117 [details] [diff] [review]: ----------------------------------------------------------------- Also, I wonder if this should be api-reference-v1.yml, so that a reference document can declare that it provides this information. Changing the schema at a particular URL seems like a recipe for making existing validations fail. On the other hand, this is a backward-compatible change. ::: schemas/api-reference-v0.yml @@ +84,5 @@ > enum: > - 0 > + apiVersion: > + description: Version of the API > + type: integer We've been careful to treat API versions as strings with a "v" prefix, to help disambiguate them from other things (like the confusing `version` property). So this should be a string with a pattern, similar to that in `manifest-v2.json`.
Attachment #9009148 - Attachment is obsolete: true
Attachment #9009148 - Flags: review?(dustin)
Oh, and I think the copy of that schema in taskcluster-lib-api will need an update? Maybe we should just hold on until we talk next week.
Comment on attachment 9009117 [details] [diff] [review] taskcluster-references patch I think bugzilla got confused about which patch I was reviewing..
Attachment #9009117 - Flags: review?(dustin)
Now that I was able to find the schema (thanks!), I've been able to get the tests working
Attachment #9009150 - Flags: review?(dustin)
Comment on attachment 9009150 [details] [diff] [review] taskcluster-lib-api patch to include api version (v2) Review of attachment 9009150 [details] [diff] [review]: ----------------------------------------------------------------- Looks good, but without the version bump in this rev. And let's hold off landing until we talk on Monday.
Attachment #9009150 - Flags: review?(dustin) → review+
Attachment #9009117 - Attachment is obsolete: true
Attachment #9009151 - Flags: review?(dustin)
Comment on attachment 9009151 [details] [diff] [review] taskcluster-references patch (v2) Let's figure out if this should be api-reference-v1.yml before r+'ing
Attachment #9009151 - Flags: review?(dustin)
(In reply to Dustin J. Mitchell [:dustin] pronoun: he from comment #14) > Comment on attachment 9009150 [details] [diff] [review] > taskcluster-lib-api patch to include api version (v2) > > Review of attachment 9009150 [details] [diff] [review]: > ----------------------------------------------------------------- > > Looks good, but without the version bump in this rev. And let's hold off > landing until we talk on Monday. Do you mean that this should be a patch release or that we should build up more changes before determining the next version number?
I think a minor rev is good -- but let's make a separate commit to bump the version number with a tag, like `npm version` does.
I think this is ready to go. I'll try to get it landed and released.
Flags: needinfo?(dustin)
tc-lib-api v12.5.0
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
See Also: → 1433672
Dustin, a gentle remember not to close bugs for changes to api-reference.json until the changes have been manually published to production, or to deploy the changes to production when you close the bug (due to bug 1433672). Thanks!
Flags: needinfo?(dustin)
done.
Flags: needinfo?(dustin)
Status: REOPENED → RESOLVED
Closed: 6 years ago6 years ago
Resolution: --- → FIXED
Component: Redeployability → Services
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: