Labels, fields, and choices go through specific states throughout their lives. Additionally, labels might have different revisions. The following diagram shows the label lifecycle, including revisioning:
- Create a label (
create())—The label is created and stored in a database asrevision_id=1. The label has the state ofUNPUBLISHED_DRAFT. In this state:- Users can't view the label
- Users can't apply the label to Drive items.
- (optional) Update a label, field, or choice (
delta())— Every update, even before it's published, is stored in a database, and the label's revision is incremented. - Publish a label (
publish())—The label has the state ofPUBLISHEDand users can apply the label. Publishing the label increments its revision. - (optional) Update a label, field, or choice (
delta())— The label, field, or choice is updated and stored in a database as a draft label. The label has the state ofPUBLISHEDwithhasUnpublishedChanges=truemeaning there are draft changes, but they aren't available to users. Each update increments the label's revision. - (optional) Publish a label (
publish())—If available, the most-current draft is published. The label has the state ofPUBLISHEDand users can apply the label. Publishing the label increments its version. - Disable a label (
disable())—The label has the state ofDISABLEDthough users can apply the label through the API. However, a disabled label isn't shown in a UI unless configured to be shown. Deprecating the label increments its revision. - Enable a label (
enable())—The label is returned to aPUBLISHEDstate and users can apply the label. Publishing the label increments its revision. - Delete a label (
delete())—The label has a state ofDELETEDand can't be applied. Deleted labels are eventually purged.
It's important to emphasize that every update to a label increments the label's revision. And, if the label has already been published, publishing it again after n updates means that its published revision number is revision + n + 1 number of successive updates.