Hi all,
I was wondering if there is an LTS-like or stable version of gitlab.
I've been using gitlab (via @sameersbn's docker-gitlab) since I think 8.11.x
But the versioning has jumped up to 8.15.x (in such a short time).
In my use case we don't need fancy thing ASAP. We'd prefer a system that causes less errors.
Here are some of the errors I've experienced.
Now I was wondering if there would be a LTS like branch on the gitlab-ce repository that we could maintain as a LTS-like or Stable branch over here as well.
Frequent updates for vulnerability fixes are fine, but updates for new functionality that may introduce bugs are the kind of things that make me hesitant to upgrade.
Gitlab has a rapid release cycle. Every month on 22. they release a new version.
(current is 8.16)
They ship always a buggy version that gets 3+ patches every cycle.
(8.15 had 4 patches)
Security patches are mostly available for the last 3 releases.
(down to 8.13)
The most "stable" version is (8.15.4) from last month. If you take this as LTS it would be safe and supported only for two months. That is not enough to benefit from.
We update our instance once a month to the latest release from last month and it takes 5 min. We had no upgrade pain since we're doing it.
As an example, when 8.16 is released, we update to 8.15.4.
I can only encourage to do the same.
@medokin Thanks for the advice!
I think the approach you take looks better than updating for every sub-sub version. (ex 8.16.1, then 8.16.2 and so on).
But the issue is that from your example, you'll be waiting for 8.16.x when 8.17 is released right?
However, we will not get the vulnerability patches for the 8.16.x once sameersbn/docker-gitlab is version upped to 8.17 right? Correct me if I'm wrong. I'd be delighted if security patches also get pushed into docker-gitlab tags. However I'm afraid only the latest version gets built into a tag.
You're right, but that happened only once last year, in that case we updated to current.
@medokin Okay! I guess when there are vulnerability issues, we can jump to the current, as it shouldn't happen to often! Thanks for the advice based on your experience :)
We update our instance once a month to the latest release from last month and it takes 5 min. We had no upgrade pain since we're doing it.
I love that your doing this. I recommend the same for people running gitlab-ce in production :+1:
we will not get the vulnerability patches for the 8.16.x once sameersbn/docker-gitlab is version upped to 8.17 right?
Maybe we can make some efforts to continue updating the last release in such cases. It's a little extra effort for the maintainers but I see this happen infrequently. WDYT @solidnerd?
I opened another issue at #1078 on the same point ;)
With the release of 8.16, 8.15.5 was also released; #1065
I'd be really delighted if this repo had another thread of tags for the stable versions ;)
@sameersbn This requires in my opinion an update of our maintenance workflow and branching model. Why GitLab can do that is that they have for every minor version an own branch. If we want to release it. We need to work with docker hub hooks. Furthermore I see this only if we got tests for our setup. The overhead comes from that we want to support old versions than It's not more overhead to support one or two versions before the current version. With the same branch strategy we are able to do it. But first I want automated tests for it.
For information about the build hooks. I can provide you some information https://docs.docker.com/docker-cloud/builds/advanced/ . This Hooks works as well on Docker Hub.Then we can control the process of builds.
Here is my personal list that things we need to releasise it.
.gitlab-ci.yml to cover tests update of our maintenance workflow and branching model.
completely agree. I was thinking create a version branch when a new major release it out. f.e. we create a 8.15-stable branch when the first 8.16 release is published. Updating the 8.15-stable branch will be infrequent i believe and we will be paving the way for users to contribute these updates if it effects them.
We need to work with docker hub hooks
I don't really realise how docker hub hooks will help.
But first I want automated tests for it.
Yep. This is a big pain point. We should be working on this with high priority. Do you have any ideas for this?
Will definitely take a look.
On Thursday 02 February 2017 03:43 PM, Niclas Mietz wrote:
For information about the build hooks. I can provide you some
information https://docs.docker.com/docker-cloud/builds/advanced/ . This
Hooks works as well on Docker Hub.Then we can control the process of builds.—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/sameersbn/docker-gitlab/issues/1058#issuecomment-276917789,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAZCI7JzEswcOYvLSn6PAbw0kI4uIiyZks5rYaxWgaJpZM4LpALr.
--
Sameer Naik
This issue has been automatically marked as stale because it has not had any activity for the last 60 days. It will be closed if no further activity occurs during the next 7 days. Thank you for your contributions.
Most helpful comment
@sameersbn This requires in my opinion an update of our maintenance workflow and branching model. Why GitLab can do that is that they have for every minor version an own branch. If we want to release it. We need to work with docker hub hooks. Furthermore I see this only if we got tests for our setup. The overhead comes from that we want to support old versions than It's not more overhead to support one or two versions before the current version. With the same branch strategy we are able to do it. But first I want automated tests for it.