I agree that it seems like a big change but there were 2 ways to fix the changelog/repo commands bug:
1) revert my previous fix; that means that the release field will keep not detecting ESM releases properly, the ESM chroot naming standardization was just a case that worked as a motivation to make all these changes.
2) keep the new field (base_release) and differentiate code that needs a full release name from code that needs just the base release (this patch)
technically a release is "Ubuntu" plus the version "X.YY" (and I guess the minor versions as well). "series" could also be the term we could use instead of "base_release" ("parent" in cve_lib) and maybe "subproject" instead of "release" (subproject is the term cve_lib uses).
I agree that it seems like a big change but there were 2 ways to fix the changelog/repo commands bug:
1) revert my previous fix; that means that the release field will keep not detecting ESM releases properly, the ESM chroot naming standardization was just a case that worked as a motivation to make all these changes.
2) keep the new field (base_release) and differentiate code that needs a full release name from code that needs just the base release (this patch)
Regarding the name, "distribution" could be an alternative one but I haven't seen that used in any of our tools. cve_lib for example uses the term "parent" https:/ /git.launchpad. net/ubuntu- cve-tracker/ tree/scripts/ cve_lib. py#n113 to indicate the same thing, so that could be a candidate.
If we wanted to be pedantic, according to /docs.ubuntu. com/landscape/ en/repositories and /wiki.ubuntu. com/Development CodeNames
- https:/
- https:/
technically a release is "Ubuntu" plus the version "X.YY" (and I guess the minor versions as well). "series" could also be the term we could use instead of "base_release" ("parent" in cve_lib) and maybe "subproject" instead of "release" (subproject is the term cve_lib uses).