LTS version of Docker #20424

Closed
icy opened this Issue Feb 18, 2016 · 30 comments

Comments

Projects
None yet
10 participants
@icy

icy commented Feb 18, 2016

I'm sorry if this issue has been discussed some place.

I am using Docker-1.8. Shortly after I can understand it (mostly) there is a new release Docker-1.9. My team is studying to upgrade from 1.8 to 1.9 and we suddenly heard there is also Docker 1.10. Omg, it's very fast!

Could you please have a LTS version, with some features/security patches are ported from the upstream? It's very useful because we would have control of our environments, not the hackers!

Thanks a ton for your great work!

Update: Fix typoe (which -> with)

@icy

This comment has been minimized.

Show comment
Hide comment
@icy

icy Feb 18, 2016

@GordonTheTurtle This is not a bug. What is your recommendation for this kind of request?

icy commented Feb 18, 2016

@GordonTheTurtle This is not a bug. What is your recommendation for this kind of request?

@icy

This comment has been minimized.

Show comment
Hide comment
@icy

icy Feb 18, 2016

My bad. I forgot to tell what I meant: LTS is Long-Term Support.

icy commented Feb 18, 2016

My bad. I forgot to tell what I meant: LTS is Long-Term Support.

@cpuguy83

This comment has been minimized.

Show comment
Hide comment
@cpuguy83

cpuguy83 Feb 18, 2016

Contributor

@icy Docker Inc offers a commercially supported version. https://www.docker.com/products/overview

Contributor

cpuguy83 commented Feb 18, 2016

@icy Docker Inc offers a commercially supported version. https://www.docker.com/products/overview

@cpuguy83 cpuguy83 closed this Feb 18, 2016

@icy

This comment has been minimized.

Show comment
Hide comment
@icy

icy Feb 18, 2016

did you mean there is no LTS version for community? We have to pay to get LTS version? Can you make this clear in the official documentation?

icy commented Feb 18, 2016

did you mean there is no LTS version for community? We have to pay to get LTS version? Can you make this clear in the official documentation?

@icy

This comment has been minimized.

Show comment
Hide comment
@icy

icy Feb 18, 2016

@cpuguy83

I have taken a look at https://www.docker.com/products/overview . It doesn't mention any LTS version at all

icy commented Feb 18, 2016

@cpuguy83

I have taken a look at https://www.docker.com/products/overview . It doesn't mention any LTS version at all

@cpuguy83

This comment has been minimized.

Show comment
Hide comment
@cpuguy83

cpuguy83 Feb 18, 2016

Contributor

@icy The commercially supported version is offered as part of a subscription under "Docker Datacenter".

re: docs update
Please feel free to open a pull request. I'm not sure saying "we don't have X" is all that helpful.

Contributor

cpuguy83 commented Feb 18, 2016

@icy The commercially supported version is offered as part of a subscription under "Docker Datacenter".

re: docs update
Please feel free to open a pull request. I'm not sure saying "we don't have X" is all that helpful.

@icy

This comment has been minimized.

Show comment
Hide comment
@icy

icy Feb 18, 2016

But I'm asking for a LTS version, not a commerical version. Does that make sense?

If your team can't have such version, just say "no" instead of providing a commerical version (it's quite rude IMHO). By saying "no", someone make have a plan to work on LTS version.

Docker rocks, but I think it's important to keep our systems healthy .Especially upgrading from 1.8 -> 1.9 (e.g.) causes a lot of problems.

icy commented Feb 18, 2016

But I'm asking for a LTS version, not a commerical version. Does that make sense?

If your team can't have such version, just say "no" instead of providing a commerical version (it's quite rude IMHO). By saying "no", someone make have a plan to work on LTS version.

Docker rocks, but I think it's important to keep our systems healthy .Especially upgrading from 1.8 -> 1.9 (e.g.) causes a lot of problems.

@cpuguy83

This comment has been minimized.

Show comment
Hide comment
@cpuguy83

cpuguy83 Feb 18, 2016

Contributor

I told you a known alternative to something that doesn't otherwise exist. I would hardly call this rude.

Contributor

cpuguy83 commented Feb 18, 2016

I told you a known alternative to something that doesn't otherwise exist. I would hardly call this rude.

@hqhq

This comment has been minimized.

Show comment
Hide comment
@hqhq

hqhq Feb 18, 2016

Contributor

I think having no LTS version is kind of docker issue, we should keep this open if there are no other issues tracking on this.

I'm totally +1 for adding LTS version support for Docker official team, any projects which are ready for production should have LTS support. Now we have our own team to maintain our own Docker LTS version, but if there is an official one, it'll make many smaller complies or teams much easier life for using Docker in production.

Anyway, if docker will only offer commercially supported, and will not maintain opensource LTS , that'll also be an acceptable conclusion to me (But I guess that shouldn't be an easy conclusion to make 😉 ), then we should add that to somewhere in doc, then close this issue.

@cpuguy83 WDYT?

Contributor

hqhq commented Feb 18, 2016

I think having no LTS version is kind of docker issue, we should keep this open if there are no other issues tracking on this.

I'm totally +1 for adding LTS version support for Docker official team, any projects which are ready for production should have LTS support. Now we have our own team to maintain our own Docker LTS version, but if there is an official one, it'll make many smaller complies or teams much easier life for using Docker in production.

Anyway, if docker will only offer commercially supported, and will not maintain opensource LTS , that'll also be an acceptable conclusion to me (But I guess that shouldn't be an easy conclusion to make 😉 ), then we should add that to somewhere in doc, then close this issue.

@cpuguy83 WDYT?

@thaJeztah

This comment has been minimized.

Show comment
Hide comment
@thaJeztah

thaJeztah Feb 18, 2016

Member

I think the current status is that we simply don't have the bandwidth to maintain multiple releases (i.e., maintain a LTS release and the current release); newer releases should be backward compatible (for example, we kept the "legacy" linking behavior for the default bridge network when we implemented the new networking).

I agree that we may need to be more clear about the bi-monthly release cycle (and not having a LTS release / not providing patch releases for older releases) in the documentation and/or README, so welcome a PR to clarify that.

Member

thaJeztah commented Feb 18, 2016

I think the current status is that we simply don't have the bandwidth to maintain multiple releases (i.e., maintain a LTS release and the current release); newer releases should be backward compatible (for example, we kept the "legacy" linking behavior for the default bridge network when we implemented the new networking).

I agree that we may need to be more clear about the bi-monthly release cycle (and not having a LTS release / not providing patch releases for older releases) in the documentation and/or README, so welcome a PR to clarify that.

@icy

This comment has been minimized.

Show comment
Hide comment
@icy

icy Feb 18, 2016

Thank you for your feedback, @cpuguy83 and @thaJeztah .

I understand Docker team has a lot of things to do. But please note, Docker users also have a lot of things to do and they may not be able to support upgrade (without or without troubles) every time, and living with legacy versions is not a good idea, e.g, without having any security patch.

My situation is now like this: I am using Docker, and I don't know what will be going on in next 6 months or 1 year. While we're planning for new Docker version there is actually a newer version which may be a must upgrade (e.g, that has a memory leak issue fixed.) And so on. :( I am not lucky enough, like @hqhq who has a team to have their own LTS.

I think many Docker users are in the same situation. We need a stable infrastructure to support agile software development; we don't need a stable software development to support an agile infrastructure. Docker now forces us to solve a wrong problem!!

Instead of closing this issue (as an alternative way to say Docker will never support LTS version), Docker team may keep it open to hear what their users think!

Thanks a lot!

Update: fix typo error (luck enogh -> lucky enough)

icy commented Feb 18, 2016

Thank you for your feedback, @cpuguy83 and @thaJeztah .

I understand Docker team has a lot of things to do. But please note, Docker users also have a lot of things to do and they may not be able to support upgrade (without or without troubles) every time, and living with legacy versions is not a good idea, e.g, without having any security patch.

My situation is now like this: I am using Docker, and I don't know what will be going on in next 6 months or 1 year. While we're planning for new Docker version there is actually a newer version which may be a must upgrade (e.g, that has a memory leak issue fixed.) And so on. :( I am not lucky enough, like @hqhq who has a team to have their own LTS.

I think many Docker users are in the same situation. We need a stable infrastructure to support agile software development; we don't need a stable software development to support an agile infrastructure. Docker now forces us to solve a wrong problem!!

Instead of closing this issue (as an alternative way to say Docker will never support LTS version), Docker team may keep it open to hear what their users think!

Thanks a lot!

Update: fix typo error (luck enogh -> lucky enough)

@thaJeztah

This comment has been minimized.

Show comment
Hide comment
@thaJeztah

thaJeztah Feb 18, 2016

Member

@icy fair, let me reopen, it's a feature request after all; discussing it doesn't hurt

Member

thaJeztah commented Feb 18, 2016

@icy fair, let me reopen, it's a feature request after all; discussing it doesn't hurt

@thaJeztah thaJeztah reopened this Feb 18, 2016

@cpuguy83

This comment has been minimized.

Show comment
Hide comment
@cpuguy83

cpuguy83 Feb 18, 2016

Contributor

FWIW, I don't think there's anyone who doesn't want something like an LTS release, maintainers included.. we are just not there yet.

Contributor

cpuguy83 commented Feb 18, 2016

FWIW, I don't think there's anyone who doesn't want something like an LTS release, maintainers included.. we are just not there yet.

@icy

This comment has been minimized.

Show comment
Hide comment
@icy

icy Feb 19, 2016

Great to hear that, @thaJeztah and @cpuguy83 ! It seems I didn't get your idea, @cpuguy83 and I'm sorry about that.!

icy commented Feb 19, 2016

Great to hear that, @thaJeztah and @cpuguy83 ! It seems I didn't get your idea, @cpuguy83 and I'm sorry about that.!

@AndrewGuenther

This comment has been minimized.

Show comment
Hide comment
@AndrewGuenther

AndrewGuenther Feb 19, 2016

Contributor

If the concern is security patches, this seems like something which could at least be partially automated.

Here's an off-the-cuff suggestion. Give security fixes (fixes specifically, not security related features) their own issue label. When a pull request is merged, you could have a simple webhook endpoint that tries to apply the patch to the LTS version branch. If it applies cleanly, submit a pull request, if it doesn't file an issue.

Now, the amount of work involved here depends heavily on how many fixes will apply cleanly. But this is a metric that could be tested before even committing to an LTS version. One nice thing is that by automatically submitting issues for failed patches, the community can assist in getting those patches applied.

This process can also be done in small chunks as well. I think a clear way to mark issues as security issues would be generally beneficial, LTS or not. Once that is in place, one could start trying to apply patches to old versions and produce data on how cleanly they apply and the discussion could pick up from there.

If the maintainers are willing to create the label, I'd be more than happy to perform the analysis. Thoughts?

Contributor

AndrewGuenther commented Feb 19, 2016

If the concern is security patches, this seems like something which could at least be partially automated.

Here's an off-the-cuff suggestion. Give security fixes (fixes specifically, not security related features) their own issue label. When a pull request is merged, you could have a simple webhook endpoint that tries to apply the patch to the LTS version branch. If it applies cleanly, submit a pull request, if it doesn't file an issue.

Now, the amount of work involved here depends heavily on how many fixes will apply cleanly. But this is a metric that could be tested before even committing to an LTS version. One nice thing is that by automatically submitting issues for failed patches, the community can assist in getting those patches applied.

This process can also be done in small chunks as well. I think a clear way to mark issues as security issues would be generally beneficial, LTS or not. Once that is in place, one could start trying to apply patches to old versions and produce data on how cleanly they apply and the discussion could pick up from there.

If the maintainers are willing to create the label, I'd be more than happy to perform the analysis. Thoughts?

@phemmer

This comment has been minimized.

Show comment
Hide comment
@phemmer

phemmer Mar 2, 2016

Contributor

I'm also interested in this, and to me it's more than security patches. A lot of times I'll run into some bug (not a security issue) for which the patch is in a new version. But upgrading to that new version often brings a ton of new bugs with it, so I have to upgrade to the next version to fix those, and the cycle repeats.

Contributor

phemmer commented Mar 2, 2016

I'm also interested in this, and to me it's more than security patches. A lot of times I'll run into some bug (not a security issue) for which the patch is in a new version. But upgrading to that new version often brings a ton of new bugs with it, so I have to upgrade to the next version to fix those, and the cycle repeats.

@cpuguy83

This comment has been minimized.

Show comment
Hide comment
@cpuguy83

cpuguy83 Mar 2, 2016

Contributor

@phemmer Generally agree, and I don't believe we've done a good enough job in making patch releases for whatever is the current version.

Contributor

cpuguy83 commented Mar 2, 2016

@phemmer Generally agree, and I don't believe we've done a good enough job in making patch releases for whatever is the current version.

@thuandt

This comment has been minimized.

Show comment
Hide comment
@thuandt

thuandt Mar 2, 2016

@icy poor you. I'm so lucky because still stuck with OpenVZ and LXC 😱

thuandt commented Mar 2, 2016

@icy poor you. I'm so lucky because still stuck with OpenVZ and LXC 😱

@thaJeztah

This comment has been minimized.

Show comment
Hide comment
@thaJeztah

thaJeztah Mar 2, 2016

Member

@thuandt please keep your comments constructive

Member

thaJeztah commented Mar 2, 2016

@thuandt please keep your comments constructive

@AndrewGuenther

This comment has been minimized.

Show comment
Hide comment
@AndrewGuenther

AndrewGuenther Mar 2, 2016

Contributor

@phemmer @cpuguy83 I think my proposal could still work for bug fix patches as well. The hardest part of this (in my mind) is just properly marking all the PRs that should be patched back.

Contributor

AndrewGuenther commented Mar 2, 2016

@phemmer @cpuguy83 I think my proposal could still work for bug fix patches as well. The hardest part of this (in my mind) is just properly marking all the PRs that should be patched back.

@yeasy

This comment has been minimized.

Show comment
Hide comment
@yeasy

yeasy Jun 15, 2016

+1, LTS is good for productive adoptions.

yeasy commented Jun 15, 2016

+1, LTS is good for productive adoptions.

@icy

This comment has been minimized.

Show comment
Hide comment

icy commented Sep 16, 2016

@thaJeztah

This comment has been minimized.

Show comment
Hide comment
Member

thaJeztah commented Nov 9, 2016

@perlun

This comment has been minimized.

Show comment
Hide comment
@perlun

perlun Sep 19, 2017

I think this is more or less "done" now with the new versioning scheme, quoting from https://docs.docker.com/engine/installation/#server:

Starting with Docker 17.03, Docker uses a time-based release schedule, outlined below.

17.03 = stable/LTS, 17.06 = stable/LTS, 17.09 = stable/LTS, 17.12 = stable/LTS.

@thaJeztah & @icy, are you fine with closing this now?

perlun commented Sep 19, 2017

I think this is more or less "done" now with the new versioning scheme, quoting from https://docs.docker.com/engine/installation/#server:

Starting with Docker 17.03, Docker uses a time-based release schedule, outlined below.

17.03 = stable/LTS, 17.06 = stable/LTS, 17.09 = stable/LTS, 17.12 = stable/LTS.

@thaJeztah & @icy, are you fine with closing this now?

@fossilet

This comment has been minimized.

Show comment
Hide comment
@fossilet

fossilet Sep 19, 2017

Contributor

Stable releases only have a 4-month long support period; by no means they can be called LTS.

https://blog.docker.com/2017/03/docker-enterprise-edition/

Contributor

fossilet commented Sep 19, 2017

Stable releases only have a 4-month long support period; by no means they can be called LTS.

https://blog.docker.com/2017/03/docker-enterprise-edition/

@perlun

This comment has been minimized.

Show comment
Hide comment
@perlun

perlun Sep 19, 2017

Quaterly releases only have a 4-month long support period; by no means they can be LTS.

Depends on what you mean by "long". 😉

But yeah, compared to Ubuntu's five year LTS, 4-months is really a short time span.

perlun commented Sep 19, 2017

Quaterly releases only have a 4-month long support period; by no means they can be LTS.

Depends on what you mean by "long". 😉

But yeah, compared to Ubuntu's five year LTS, 4-months is really a short time span.

@icy

This comment has been minimized.

Show comment
Hide comment
@icy

icy Sep 19, 2017

@perlun Yah it's fine. We decided not to use Docker in the current infrastructure :( Anyway I always hope there is a better support. Best wishes, Docker team.

icy commented Sep 19, 2017

@perlun Yah it's fine. We decided not to use Docker in the current infrastructure :( Anyway I always hope there is a better support. Best wishes, Docker team.

@icy icy closed this Sep 19, 2017

@thaJeztah

This comment has been minimized.

Show comment
Hide comment
@thaJeztah

thaJeztah Sep 19, 2017

Member

Forgot about this issue; yes, stable releases of Docker CE (Community Edition) are supported for 4 months, and Docker EE (Enterprise Edition) for 12 months.

Member

thaJeztah commented Sep 19, 2017

Forgot about this issue; yes, stable releases of Docker CE (Community Edition) are supported for 4 months, and Docker EE (Enterprise Edition) for 12 months.

@perlun

This comment has been minimized.

Show comment
Hide comment
@perlun

perlun Sep 19, 2017

@thaJeztah Maybe this is the wrong forum, but is there any way to get longer support than 12 months? One concrete example from real world: one of our customer are now replacing one of their servers. It has been running in production since November 2014, using an older version of Debian. It is now being replaced with a newer installation (Ubuntu 16.04 LTS).

If this machine was running Docker (which it isn't in this case, neither the old nor the new server), we would have been forced to either:

  • Use an unsupported version of Docker for a couple of years (after September 2015), or
  • Force the customer to upgrade a working production environment to a new, potentially not-100%-compatible version, two times.

How on earth do you expect us to be able to motivate this to the customer in question? Why should they be forced to pay the potential costs it can incur on them? (not to say, take the risks that it can cause for the core of their business.)

(I don't intend to be rude in any way, sorry if I'm perceived that way. I just happen to agree that 12 months for a "long-term" supported version is a very, very short amount of time on a corporate time scale.)

My 0,02€: consider expanding the Enterprise Edition to something more than 12 months (say, 3 years or 5 years). Charge a higher price for that package if needed. I think you would definitely have more customers this way, and also show that you take corporate adoption more seriously. (Maybe these kind of longer-LTS options are already available, I don't know of them personally.) It's simply not realistic to expect all customers to upgrade major versions every year.

perlun commented Sep 19, 2017

@thaJeztah Maybe this is the wrong forum, but is there any way to get longer support than 12 months? One concrete example from real world: one of our customer are now replacing one of their servers. It has been running in production since November 2014, using an older version of Debian. It is now being replaced with a newer installation (Ubuntu 16.04 LTS).

If this machine was running Docker (which it isn't in this case, neither the old nor the new server), we would have been forced to either:

  • Use an unsupported version of Docker for a couple of years (after September 2015), or
  • Force the customer to upgrade a working production environment to a new, potentially not-100%-compatible version, two times.

How on earth do you expect us to be able to motivate this to the customer in question? Why should they be forced to pay the potential costs it can incur on them? (not to say, take the risks that it can cause for the core of their business.)

(I don't intend to be rude in any way, sorry if I'm perceived that way. I just happen to agree that 12 months for a "long-term" supported version is a very, very short amount of time on a corporate time scale.)

My 0,02€: consider expanding the Enterprise Edition to something more than 12 months (say, 3 years or 5 years). Charge a higher price for that package if needed. I think you would definitely have more customers this way, and also show that you take corporate adoption more seriously. (Maybe these kind of longer-LTS options are already available, I don't know of them personally.) It's simply not realistic to expect all customers to upgrade major versions every year.

@cpuguy83

This comment has been minimized.

Show comment
Hide comment
@cpuguy83

cpuguy83 Sep 19, 2017

Contributor

@perlun This definitely isn't the right forum, but in terms of redirecting elsewhere i'm not sure. For EE certainly a sales rep or account manager... If you want to talk about the community edition, then github.com/docker/docker-ce. Honestly the CE story is much better than it used to be where support was only for the currently released version, no overlap, and generally 2-3 month release cycle.
One thing to keep in mind is Docker is only 4 years old.

Contributor

cpuguy83 commented Sep 19, 2017

@perlun This definitely isn't the right forum, but in terms of redirecting elsewhere i'm not sure. For EE certainly a sales rep or account manager... If you want to talk about the community edition, then github.com/docker/docker-ce. Honestly the CE story is much better than it used to be where support was only for the currently released version, no overlap, and generally 2-3 month release cycle.
One thing to keep in mind is Docker is only 4 years old.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment