Debian stable releases (and their users) require long-term security support for whatever version is packaged, and thatās a deliberate choice for their use-case. It shouldnāt be that hard if the timing is well co-ordinated, such that the latest feature-complete version lands in Debian shortly before freeze (November 2016), and upstream made some long-term (2-3 years?) commitment to identify (e.g. file CVEs) and try to fix security bugs in that version.
The only ways to get that wrong, are if a rapidly changing development version went into Debian sid/testing too soon (and thus requires substantial changes after the freeze date); or if upstream doesnāt clearly identify or make easy to backport patches for security bugs. (e.g. Oracle MySQL, not detailing the security bugs fixed, adding arbitrary new features in a maintenance release, and not even having public source version control ).
By all means call the long-term supported version by some other name / numbering scheme if you want to differentiate it from the very latest vendor release, but please donāt use trademark law to threaten distributors.
Also, Debian users expect a smooth upgrade between major versions of the OS, so that needs to be supported by applications too.
In my opinion, web apps shouldnāt even be packaged for distributions. Youāre almost certain to run into issues as soon as you install another one, with different requirements. Things breaks when you try to configure things a bit differently, updates break, etc.
If you require LTS support for a web app, get an enterprise contract.
Fine, this thread is about not blocking people in doing so.
[quote="oparoz, post:5, topic:89]If you require LTS support for a web app, get an enterprise contract.
[/quote]
Iām not following. LTS was not promoted at owncloud.com, so I am a bit surprised that this should have made the difference. Note, that ownCloud 7 was supported until recently. (In some way v7 is probably still covered, since there have been no new security fixes for 8.x since then.) However, when v7 was still supported you would have to do 4 upgrades to get to v9.
True and I wonāt comment about the use of IP laws to protect a product. I just donāt want distros to start dictating how and when to release NC.
Users can stop using packages and switch to something else, like containers or simply Ubuntu Snap.
But that requires a change in processes and it may not be that easy to introduce, depending on the type of organisation.
My comment was about the previous post which mentions smooth upgrades between major version of an OS. I should have used quotes.
The way distros do LTS only works for Linux itself and some apps which evolve really slowly. Thatās one reason Ubuntu introduced Snaps. If Debian wants to jump 9 version every 3 years, then they should provide the required scripts to make it happen, not NC and it will be a mess and people will blame NC.
If a company needs to stay on a very old version of an app because itās integrated with other solutions per example, then itās always a good idea to have a support contract to help with the migration to a more recent version.
Thatās certainly an honest answer to the original question.
Iām quite happy most other maintainers prefer to be nice towards their users, so I donāt have āenterprise contractsā for every bit of moderately complex software from the stable distributions on my servers.
Iāll be keeping a close eye on both projects and continuing to package OwnCloud updates for the foreseeable future.
Once there is an initial beta release here then Iāll take a look at the packaging requirements for that and see how it will go attempting to get it through package review.
It is a fair amount of time just testing OwnCloud (see my own blog for a view of how much time it takes to package and test each update) so Iāll make no promises about NextCloud of course ā¦
Assuming it is not too painful to package (given my existing OwnCloud knowledge and activities anyway) Iāll certainly be of a mind to do so, but the difficulty will come as the two projects diverge in time and any library dependencies that may end up differing.
TL:DR; Keeping an eye on it, will have something more meaty to say in coming weeks.
ownCloud used to have a 6 months release cycle where new releases came out. Now if an LTS distro ships an ownCloud version the releases keep piling up til the next release. Take Debian LTS for example: 5 years support amounts to 10 releases.
Upgrading a web app is not as simple as a desktop app or system utility because you have to worry about database migrations in addition to configuration and files (and the upgrade process is already fragile enough ;D). Furthermore Debian is not the only long term stable distro. You see this gets out of hand pretty fast and would require ownCloud to run upgrade tests for hundreds of different upgrade paths so the current decision is to limit this to only the previous version.
The release model does not fit with Debians release cycle so Debian maintainers patched out the safety lock for the previous version update requirement. People voiced their frustration on both sides, etc.
I honestly donāt know if this will ever be solved. The only solution I can think of is to release new versions only every 5 years or something like that which is just bogus.
Debian was first to implement a working automatic upgrade script, and OC could have adopted that instead of showing disrespect for the people working on it. Distributions have lots of users and do much work to āsanitizeā software. Seeing NC following the same path is disappointing to say the least.
@xav the issue has been discussed to death already. The general gist is: their way of upgrading is not considered to be a solution by the developers and it was more of a communication issue, no hard feelings.
To summarize my answer: we are friendly and open to any collaborators, also package maintainers, but IMHO it will either take a long time or not be possible to upgrade from a version which is not a direct predecessor
I think there are mainly two problems to solve. One is on the Nextcloud side and one is on the Distribution side.
make it possible for Distributions and users in general to upgrade also across multiple major versions. I think this is something we definitely can and should improve. I thought I read already a thread about it by @LukasReschke but I canāt find it any more.
Distributions need to find a way to keep their version secure. I think thatās especially crucial for software running on a server, like Nextcloud. I donāt really know how this can be handled on a Distribution side without updating at least to the latest bug-fix releases. But I think thatās a important point need to be solved to keep the users secure.
If NC could designate one version/branch as ālong-term supportedā at a time, youād only need to support two types of upgrade:
upgrade to latest (major or minor) version from previous version (for people who update often)
upgrade to new LTS from previous LTS (this is basically what Debian tried to do, but if the developer does this, great)
And although Debian LTS releases are supported for 5 years, not every application has to be part of that, the official stable release only has a life of 3 years (plus ~6 months between the freeze and release).
But since the LTS version will be different for each distribution, itās not just one LTS version and upgrade paths isnāt it ?
Supporting a LTS version is also not only about upgrade paths, there are also critical fixes backports.
Disclaimer : Iām no employee of NC myself. This is just IMHO.
I donāt think you should interpret posts in the forum as the official stance of NC, at this point they are only personal opinions in a discussion.
The project just started and right now a lot of things are in the process of being figured out.
Relationship with package maintainers are no exception and this is a great time to make your opinion heard.
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.
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
Seems to me that with the adoption of snap packages across distros (see Adios apt and yum? Ubuntuās snap apps are coming to distros everywhere | Ars Technica) 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ā¦)
With some luck even today!