With our current release process we need to push a tag to all repositories we bulk-manage. On the GitLab Web frontend this is a bit time-consuming, and actually error-prone (you can easily overlook repositories).
On the command line we could easily do that quicker using just git, but we'd need to close every single repository. We should probably better do that via GitLab API calls.
Given that we'll release frequently and more in terms of "reflect the current state of are" (not in terms of release "features of a product") semver is likely less suitable as a versioning scheme than something that better reflects both a date/time "bandwidth" of release activities and blends in well in automated operations (e.g. increment last number when several releases need to be done). This might be a date-based scheme, e.g. YYYY.MM.c with c being a monthly release counter starting at 1 each month (or YY.MM.c like Ubuntu does it). EDIT: (see explanation below)
Needed Features
- List latest tag(s) of a number of repository (e.g. project filtered by
--topics), detecting whether there are unreleased commits
- Set a tag on a number of repositories (as listed earlier)
Examples
(See comment below)
With our current release process we need to push a tag to all repositories we bulk-manage. On the GitLab Web frontend this is a bit time-consuming, and actually error-prone (you can easily overlook repositories).
On the command line we could easily do that quicker using just
git, but we'd need to close every single repository. We should probably better do that via GitLab API calls.Given that we'll release frequently and more in terms of "reflect the current state of are" (not in terms of release "features of a product") semver is likely less suitable as a versioning scheme than something that better reflects both a date/time "bandwidth" of release activities and blends in well in automated operations (e.g. increment last number when several releases need to be done). This might be a date-based scheme, e.g.EDIT: (see explanation below)YYYY.MM.cwithcbeing a monthly release counter starting at 1 each month (orYY.MM.clike Ubuntu does it).Needed Features
--topics), detecting whether there are unreleased commitsExamples
(See comment below)