Support Cycle / Number of maintained versions

Super good news, Jan! Thanks for the update! That helps us planning our updates :slight_smile: .

@jospoortvliet: Any official statement planned? People need to know as soon as possible especially if underlying software needs to be upgraded as well. 4 weeks is not very muchā€¦

Yeah, good point, we should announce this. And for 14.04 users we should consider offering a few more weeks or something like thatā€¦ I will discuss.

1 Like

Weā€™ve put it in various places like the changelog & release schedule on the wiki and the last update blog. Weā€™ll mention it also in other places (eg 12 release announcement) but donā€™t plan to do a separate blog.

FTR the release schedule has been updated again https://github.com/nextcloud/server/wiki/Maintenance-and-Release-Schedule reflecting the latest status/date on the NC11 EOL which is now set to the NC13 release date (which is probably somewhere close to end of 2017 - just a guess!)

1 Like

@jospoortvliet what about moving the EOL date for a release not to the next release but one but to the first minor version of that release.
Now the support looks like the following:
11 -> EOL Release date of 13

I would sugget the following:
11 -> EOL Release date of 13.0.1

With the current cycle we (and probably other users) would have to update roughly every 5 months because we try to never update to a major Release directly but to the first minor (bugfix/security) release of a major version. The first version of a major release has often some nasty issues which are only found, once the release has gone public (I canā€™t back prove this statement with facts right now. This is my personal overall experience with software. Please correct me if this is not the case with NC).

If the support lasts to the first minor release of a major release we would have the opportunity to stay with a release easily for (roughly) up two 10 months. Of course there may be important security issues or bugfixes affecting us which may force us to update to every minor release. But from my experience the first minor release often contains the most critical updates to a new major release and after that the issues are mostly not so urgent to update again so soon.

2 Likes

Yeah, Tom, this is pretty much my thinking too and probably what weā€™re going to do :wink:

But we have to sit down and put dates on it, yes. That still has to be done, weā€™ve worked very feature-driven in the last months and we want a more time based schedule so we can make these promises. Will probably be a subject for our next hackweek in Stuttgartā€¦

1 Like

Help me understand v9 e.o.l please Jos, are we talking full loss of support and no further security patches, or just no further feature releases/backports?

Ending a prior version on the point release of the next is definitely the way to go. Looking at the state of 12 at the moment for example will likely have me waiting on 12.0.1 before updating, just to be sure my critical data is safe once the teething is over.

For nine we will certainly do no more updates at all, including security. Nobody should use it except customers. 10 will follow, probably after the 12.0.1 release yes.

Note that companies, which typically are the ones that want to stay on a specific release, can get extended life cycle support from us for a fee, up to 15 years. Maintaining old versions is boring, no volunteer wants to do it - so that has to be paid for by somebody :wink:

But patches and fixes that come as part of this support will never make it out to the community, regardless of severity.

Correct. Home users should upgrade regularly. Small businesses, too - there are rarely good reasons to stay on an old version, besides ā€œI donā€™t want to spend time on upgradingā€, to which I say ā€œin open source, you pay in either time or moneyā€.

The main reason for long-term support is that large enterprises rely on supported software that has to work together. Think of a company with a support contract with Red Hat. They want a Nextcloud version that works with their supported Red Hat software, so for them we have to maintain specific versions which work with their infrastructure. And if they stay on a 10 year supported RHEL version, we have to match. We do that upon request, for specific customers with a support contract.

It all makes sense, Iā€™m just fishing for clarity :slight_smile:

Thanks for that.

1 Like

Thanks. Iā€™d love to say ā€œwe will provide updates for 10 years for free for everybodyā€, but sadly that just doesnā€™t help us pay developersā€™ salaries :wink:

2 Likes

RHEL 7 sports PHP 5.4 (officially EOL but supported by Red Hat engineers until 2024), which is incompatible with Nextcloud 11 and 12. Last working version for PHP 5.4 was Nextcloud 10, which is officially unsupported. Of course I can always pull in more recent PHP version from third party repos, but this way Iā€™m losing enterprise support for my server. Iā€™m a bit surprised that the Nextcloud developers donā€™t think about such details.

1 Like

Go blame RHEL devs not Nextcloud devs.

And welcome to the Linux world!

Actually, you can get support for Nextcloud 10 if you want it, be sure to mention this when you ask for a quote: Get A Quote - Nextcloud

Providing this kind of long term support for enterprises is exactly how we earn our money. We even work with Red Hat on this so you would be able to run any version of Nextcloud and its dependencies and NOT loose the enterprise support you have.

3 Likes

Reading this post Iā€™m not so sure Iā€™ve choosen the right product for my (personal, little, no profit) server.

First of alI understand that people need to pay bills and that enterprises can (and should) buy the support NC offers to them.

Anyway I moved my data into NC because I thought it would be a safer place for it. Iā€™m an experienced administrator and I want privacy, security and availability for my data, so a private server running owncloud (and nextcloud after a while) seemed to me the best option.

This because it was both opensource and free.

Reading this post it seems to me NC want to be not only an opensource project, but a BIG one. One that hires hundreds of people, used by goverments and so onā€¦ This is good, but difficult to achieve from day one (so to speak).

You cannot tell people that you will force them to update their servers (introducing downtimes, risks, effort, ā€¦) every few months just because they donā€™t pay your support.

Even small paying customers are welcome, but not too much!

Many opensource projects out there are being developed, supported ,suggested as solution to customers by volounteers that trust them.

But, I suppose, people should help this project to grow, for free, even if the projectā€™s lead is not so grateful to themā€¦

Now Iā€™m puzzledā€¦

1 Like

For me the offers for private and commercial/official users fit quite good:

  • For fast development (thus stay on top in terms of security, stability, performance and features) you need a large user space, people who just give feedback, ideas, possible bug reports, people who go a bid deeper, just professional or personal interest, providing PRs (on github), develop apps or even decide to try to become an official nextcloud developer. This will also potentially fill conferences and lead to an overall alive community.
  • A community would never become like this, if the product is not free and will stay as limited, as features (features! not LTS) are offered limited to the free users (ownCloud <> Nextcloud).
  • For mentioned fast development is is necessary to drop support for old software by times to reduce old library/script/code overhead, close security holes, simply to reduce programming and bug tracking time by far. Thus the average free user needs to update his software regularly.
  • This is fine because by this new features will be tested and bugs reported faster, than if most people stay on old versionsā€¦ And I guess there are rare private home servers, where the uptime/reliability is that critical that one update/upgrade per month is not possible.
  • For the enterprise/official users with thus critical stability and uptime demand on the other hand, the individual long time support or their running systems is available against charge.
  • By this role allocation the paying customers also benefit from the huge amount of ā€œtestersā€ (free users, not beta testers, as the releases are quite stable of course, but as every software, the ongoing minor updates further improve and fix the initial major version) and thus get an even more stable round product as they decide to upgrade to a newer nextcloud major version. Fair game for my point of view.

kikinovak https://help.nextcloud.com/u/kikinovak
September 19

RHEL 7 sports PHP 5.4 (officially EOL but supported by Red Hat engineers
until 2024), which is incompatible with Nextcloud 11 and 12. Last working
version for PHP 5.4 was Nextcloud 10, which is officially unsupported. Of
course I can always pull in more recent PHP version from third party repos,
but this way Iā€™m losing enterprise support for my server. Iā€™m a bit
surprised that the Nextcloud developers donā€™t think about such details.

Visit Topic
https://help.nextcloud.com/t/support-cycle-number-of-maintained-versions/2508/45
or reply to this email to respond.

In Reply To
jospoortvliet https://help.nextcloud.com/u/jospoortvliet Marketing & PR
January 3
That is correct. It is one of the main benefits of a support contract. It
goes up to 15 year, I believe, though it depends a bit on platform/OS
releases. Our goal is to maintain Nextcloud releases in alignment with RHEL
and SLES releases, so you can pick a platform (RHEL 7) and a Nc release (eg
11ā€¦

Visit Topic
https://help.nextcloud.com/t/support-cycle-number-of-maintained-versions/2508/45
or reply to this email to respond.

To unsubscribe from these emails, click here
https://help.nextcloud.com/email/unsubscribe/b7af947233d11286ac16ff340142727656888362bbc2830d0439898d2e5b47a7
.

Reading my post keep in mind postfix ( the MTA I use for mailservers: is opensource, free and used all over the world).

First of all you used many bullets, but one idea really: free users should do volounteering as developer and beta tester in order to debug the ā€œenterprise/officialā€ (I woould say ā€œpayingā€ customers).

Perhaps you can do that in your home. And not for ā€œfamily criticalā€ data. For sure not in small/med companiesā€¦

Try selling this to your customer while youā€™re suggesting NC as part of your solutionā€¦

This is generally fine if you can choose to upgrade when the new code is stable enough to be worth the risk.

So, to summarize, Iā€™m just a bit worried about NC attitude towards the non paying users because I feel like, at some point, Iā€™ll have to rush in order to find some NC replacement.

1 Like