Super good news, Jan! Thanks for the update! That helps us planning our updates .
@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.
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!)
@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.
Yeah, Tom, this is pretty much my thinking too and probably what weāre going to do
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ā¦
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
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
Thanks for that.
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
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.
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.
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ā¦
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 19RHEL 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.