Hi everyone,
I’m using some self-hosted free tier GitLab right now, which doesn’t support scoped labels. Though, I have the use-case of those scoped labels for some labels like in the following example:
prio_1
prio_2
prio_3
prio_4
Does it make sense to create those labels using the naming scheme of scoped labels already, so that once we update to a premium tier those instantly provide the functionality of scoped labels?
prio::1
prio::2
prio::3
prio::4
Or would I need to re-create all of those labels anymore, because scoped labels or specially marked or whatever when creating them only? From the docs and the speedrun video I have the impression that things only depend on the naming scheme of the label, so following the naming scheme of scoped labels right now would be fine for possible premium in future
Thanks!
The issue about implementing the feature seems to provide all answers I need:
A scoped label is a specific kind of label defined only by a special colon syntax in the label’s title, namely key::value. There is no different way to create and otherwise manage scoped labels. There are just regular labels in that sense. A label is a scoped label when its title follows that syntax.
Also, it means that in previous releases (or in lower tiers), issues/mrs/epics may already have multiple scoped labels with the same key assigned. In this case, when the GitLab instance is upgraded to this version and tier, the data is not changed. However, the moment that a user applies a new scoped label with the same key, to an issue with already applied scoped labels with that key, all those existing scoped labels will be removed from that issue per the above logic.