Actually I was trying to suggest NC designate a single release branch as LTS, so that stable distributions can all use that, rather than each picking some arbitrary version and hoping itâll be supported. Ideally something like Firefox ESR.
1 Like
I see, sorry I misunderstood your meaning.
That would be a better solution indeed.
1 Like
An LTS release would also make app development easier as breaking changes wouldnât probably happen that often.
I got curious how other web apps were dealing with LTS requests and here was Wordpressâ position in 2010: LTS = Long term suckage
I would rather have them hating some other out-of-date CMS. I would
rather the IT department do two hours of work every 3-4 months than a
two-month death upgrade project every 5 years.
Another quote
I would rather invest 100 hours
in backward compatibility in a new version than 2 hours in backporting a
fix to an obsolete version of WordPress. Plus, as noted by everyone
else, backporting was often impossible because it wasnât one or two line
fixes, it was architecture changes that would touch dozens of files. The
LTS was actually less stable with these âfixesâ backported because it
had almost no one using it
2 Likes
Seems to me that with the adoption of snap packages across distros (see http://arstechnica.com/information-technology/2016/06/goodbye-apt-and-yum-ubuntus-snap-apps-are-coming-to-distros-everywhere/) snap is an increasingly reliable format - the auto-update option is a great feature, as is the bundling of dependencies (note that there is also deduplication, snap will not duplicate dependencies, but enables several versions of a package to coexist if different apps need them - the sandboxing that snap ensures also seems a nice securoty featureâŠ)
Mark Shuttleworth himself noted:
Great to see a Nextcloud snap so quickly! This should âjust workâ on any distro now, thanks to snapd being ported to all the major Linuxes.
https://plus.google.com/+MarkShuttleworthCanonical/posts/ZW52xHnDp91
Maybe Nextcould core devs could consider getting behind one of these efforts to have an official nexcloud snap?
1 Like
Yes, I do believe that thatâs the way forward.
There was an effort started with the collaboration between ownCloud and WD Lab on a âPiCloudâ which should have brought an official snap, but the 1st version had performance issues and that effort has stalled due to the lack of interest from users and resources.
The current Nextcloud snap from the app store is basically the same one, provided by Canonical.
I have no doubt that things will improve though as anybody can create a Snap or adapt the current one, so a team of volunteers might one day be assembled to work on that or NC could allocate resources to develop an official version or fund the effort.
Iâm more of this opinion: http://kmkeen.com/maintainers-matter/ but it doesnât seem widely spread here.
Iâm of the same opinion, but not for web apps unless they can be isolated like in a snap.
For those following this particular discussion thereâs a preliminary package in COPR now for testing use.
This will almost certainly be the basis of my review request there coming up soon:
https://copr.fedorainfracloud.org/coprs/jhogarth/NextCloud/
I havenât yet decided what to do with OwnCloud in Fedora/EPEL or if Iâll try and do an automated switch from oC to nC there.
1 Like
Iâd say that providing up to date packages is a great idea and Iâd like to invite distributions to do that.
So distributions with a rolling model or a short release cycle like Arch, openSUSE Tumbleweed, Fedora or Debian Unstable/Testing could easily include Nextcloud packages and - please, guys and girls, do. Anything we can do to help, ask us!
For a more LTS focused distribution there are two problems:
- long term bug and security fixes are something very few volunteers want to work on (most barely fix bugs in the stable release but only in development versionsâŠ).
- Nextcloud canât skip upgrades. And I donât think it is OK running people through 5-10 upgrades at once at the end of the period.
It wonât be easy to find people willing to do bug and security fixes for 10 years. I sure wonât be willing to force volunteer developers to backport every fix for that long. A low barrier to contribution to Nextcloud is important to us.
We want to make it possible to skip releases, so that concern might go away in a future release, but weâre talking at least 2-3 releases from now, I think. An alternative would be to built a hacky way to skip upgrades which risks usersâ data - something we would get very upset about (again). Usersâ data is holy, not risking it is rule 1 of Nextcloud.
But it was planned: https://statuscode.ch/2016/06/nextcloud-and-its-planned-update-improvements/
Did you drop this idea?
PHP itself has 2 years full support + 1 year security updates (https://secure.php.net/supported-versions.php). CentOS backports fixes but I donât know if they do it for all sorts of web application.
Ubuntu LTS support (5 years) only applies for packages from main. There are likely some unsupported packages: ubuntu-support-status --show-unsupported.
NC releases receive security updates for 18 months, thatâs a considerable period of time. If you can skip major upgrades this would mean you must do a upgrade every 18 months. But how to implement this into the distribution packages? Would it help to provide a NC LTS with a support cycle of letâs say 2 years, and cut support a bit for other versions? To comply with the release cycle of Debian/Ubuntu it should be rather 3 years. Or they have to do a major NC upgrade at mid-term?
1 Like
no, Iâm just saying it isnât implemented yet.
With regards to the 18 months, thatâs waaaaaaaay not long enough for Debian, RHEL or SLES and, indeed, even Ubuntu LTS with its 5 years⊠RHEL and SLES are supported for a decade or so.
The distroâs could decide to do major upgrades during this period, that would solve the problem of course.
Not sure, but i remember RHELâs support is not covering software like owncloud. So I donât know of examples where 10 years would apply. Never the less: Thatâs the question that distributions answer when packaging software. I donât think that known security issues would just remain unfixed in Debian stable. The seperate Debian LTS team might just drop support for Nextcloud. As with a direct Nextcloud installation you would have to upgrade, in this case your distribution from LTS to old-stable or stable.
Still for me the question remains, will you threaten downstreams with trademarks again?
You could save space by using âfolksâ while being even more inclusive 
It would be great if you wouldnât mix things up. Owncloud was distributed via the âuniverseâ repository. Itâs not officially supported, and also practically there is not LTS support at all. You canât blame other distributions for Ubuntu having such a nontransparent security support policy (VLC player and Chromium are also in âuniverseâ).
2 Likes
Are there more than two biological sexes :D?
Well anyways, Iâm totally confused now with all the different support periods. Does that mean we keep everything as is and let others worry about it?
Not in principle, but we havenât done it before either. Only if people do stuff that would make Nextcloud look bad - for example, things that threaten user data, or adding spyware. But thatâs always been a rule in our trademark guidelines.
RHELâs support doesnât cover Nextcloud or ownCloud, the idea is that those companies get paid by customers for support of their software on RHEL.
So your company deploys RHEL 7.2, which has 10 years RH support. You then buy Oracle version whatever, which also has 10 years for that RHEL release. And you get Software X, also 10 years supported with Oracle version whatever and RHEL 7.2. Now you have a platform you can use for 10 years, and you pay gold for that to Oracle, RH and the vendor of Software X because they need money to pay their engineers to work with stuff so old nobody sane wants to touch it with a 10 foot pole.
So here is a concrete invitation: we provide a space for anyone to built distribution packages:
Ask and youâll be added with the karma to get stuff going.
If you prefer to work on this within your distributionâs structure that is totally cool with us too, of course. We just want to facilitate!
Now get crackinâ!
3 Likes
This isnât solving anything. The problem has never been to find a repository/bugtracker/infrastructure to develop packages. The problem is NCâs attitude towards downstreams users who just want to apt-get install nextcloud and know itâll work.
1 Like
Well, our attitude is: âit would be awesome to have, how can we help someone who has packaging knowledge to make it happen?â
Not sure how that is a problem 
In any case, there are packages: https://repo.morph027.de/
See
https://morph027.gitlab.io/post/nextcloud-install-via-packages-on-jessie/
Not sure how we missed this 
Try them, tell me if they work, please!
1 Like
How can you help ? Easy ! Allow the packaging guy to integrate NC nicely within its distribution, i.e.:
- have some stable maintained versions.
- allow migration from one stable version to the other (even if the migration script is written by the distro maintainer).
- do not threaten people if they donât maintain your software the way you would like them to.
have some stable maintained versions.
Check
allow migration from one stable version to the other (even if the migration script is written by the distro maintainer).
There is currently still code that canât deal with this. Also distro maintainers in the past did not write migration scripts but they are of course free to do so
do not threaten people if they donât maintain your software the way you would like them to.
There never were threats but people were displeased with communication and like you pointed out some distro maintainers turned off the check while not writing migration scripts so they broke peopleâs installs.
1 Like