New Release Workflow
Now that we are on gitlab.com and properly integrated in GitLab itself we have the chance to take advantage of adopting a few processes and workflows that are established in other GitLab projects.
This issue focuses on the Release aspect and the planning of these.
Background: What we did on GitHub
On GitHub.com we made use of Milestones which were 1:1 related to a (upcoming) provider release. It worked as follows:
- Created a Milestone for a future release
- Assigned Issues and Pull Requests to them
- Eventually assigned a date when the release should happen
- Released the provider
- Closed the milestone
Pretty straight forward. We also weren't too strict on any release cadence nor scope.
The provider releases were independent of the GitLab Product Releases, however we tried to release a provider tested against new GitLab releases as soon as it was available.
What we have available now
The provider is officially maintained by the Configure Group.
To get metrics from the work we are doing here it is important to assign a few labels: sectionops ~"group::configure" ~"devops::configure"
In addition, it would also make sense to track the work we are doing related to the GitLab Release cadence, which would mean to assign Issues and Merge Request to a GitLab Milestone, e.g. %15.6 (for the current cycle).
I see a few options with both up- and downsides.
Option 1: Fully align with GitLab versioning and cadence
This would mean that:
- we release a new
major.minor
release every 22nd of the month, like we do for GitLab- we would make a jump from the provider release
v3.X
tov15.X
- we could also think about having a major release (incl. interface breaks if necessary) once a year at the same time GitLab does
- we would make a jump from the provider release
- we use the GitLab Milestones, e.g. %15.6, %15.7 for planning and tracking Issues and Merge Requests
Pros | Cons |
---|---|
Tracking works out of the box | Weirdness that a provider with version 15.6 might be compatible with all kinds of GitLab releases 1
|
Workflow aligned with other projects, e.g. gitlab-agent
|
Option 2: Use GitLab Milestone, but have our own versioning and cadence
This would mean:
- we use the GitLab Milestones, e.g. %15.6, %15.7 for planning and tracking Issues and Merge Requests
- we release independently of GitLab w.r.t the version and cadence
- each provider release would be scoped in 1 or more GitLab Milestones
- we could use an Epic per provider release to track all Issues and Merge Requests that belong to it
Pros | Cons |
---|---|
Tracking works out of the box | Workflow not aligned with other projects, e.g. gitlab-agent
|
Freedom of releasing when we feel like it | Assigned Milestones in Issues and Merge Requests don't point directly to a provider release and are ambiguous |
Unclear when to expect new releases (as today) |
Option 3: Keep as-is
This would mean that we keep everything as-is: we have our own milestones and fully independent releases.
Pros | Cons |
---|---|
Freedom of releasing when we feel like it | Tracking doesn't work (out of the box?) |
Known and working workflow in the provider | Workflow not aligned with other projects, e.g. gitlab-agent
|
Unclear when to expect new releases (as today) |
Summary
The above options don't have any weights assigned to the Pros and Cons because I think in this case it's a perspective thing, e.g. a GitLab Team Member may be biased to favor the alignment with other projects while community contributors care more about a simple process clear in the context of the provider.
However, given that tracking and alignment are an important thing (for GitLab Team Members at least) and the downsides are not huge for Option 1
I'd favor it.
Feedback
I'm wondering if I've missed some notable Pros and Cons or even Options and want to ask for feedback and opinions here, so please leave your comments
-
The provider is currently officially supporting
N-1
GitLab version whereN
is the latest GitLab release by the time that particular provider was released. However, it may be compatible with all kinds of GitLab releases. For example the provider release %v3.19.0 may be compatible with GitLab %15.5, %15.4 all the way to %14.5 for some resources / data sources. Releasing the provider with GitLab aligned versions, e.g. %15.6 could cause some confusion for end users who may assume that this provider release is only compatible with GitLab %15.6 - which is not the case. A mitigation for this is proper documentation about how we version our releases.↩