I recently noticed that while the GitLab gitlab-ce repo uses version branches (i.e. a branch per stable version with minor release tags thereon) other gitlab-org repositories, such as the gitlab-shell put stable build tags on the master
I’m curious why this is?
At a guess I’d say it’s because the gitlab-ce is a larger project where different past versions might still be in use and require patching, such as for security patches, whereas the shell has a more directly linear, fix/add-feature, then tag release.
But how does this work for this specific case where gitlab-ce uses gitlab-shell? Maybe a gitlab-ce release branch is pegged against a specific gitlab-shell release, but then what happens if a patch to gitlab-ce requires a bump to the gitlab-shell version where the newer gitlab-shell is not backwards compatible?
To continue guessing: in such a case users would be recommended to update to a newer gitlab-ce release branch - but then why not do this in the first place and have gitlab-ce use the same workflow as gitlab-shell? Is it merely down to the larger complexity/size of gitlab-ce and the fact that it is essentially the end-product for the user? And wouldn’t the reverse also hold true? (i.e. that if gitlab-shell repo used the same workflow as gitlab-ce, then a patch wouldn’t require a shell version bump and users of gitlab-ce wouldn’t have to update to a newer release branch).
Maybe there’s just some trade-off and resulting essentially arbitrary decision, as I’m still learning what git workflow best suits which contexts I’d be interested to know what led to it.