As decided in bug 20953, I have uploaded nextcloud version 10.0.5 to backports testing. The only rpm is a noarch nextcloud-10.0.5-1.mga5
Keywords: (none) => BackportCC: (none) => lists.jjorge
(In reply to José Jorge from comment #0) > As decided in bug 20953, I have uploaded nextcloud version 10.0.5 to > backports testing. > > The only rpm is a noarch nextcloud-10.0.5-1.mga5 I have never used OC/NC so thought this would be an opportunity to test and learn. I installed NC from 5/backports_testing on my Mageia 5 server and then looked for 'man nextcloud'. Nothing. I then looked in /usr/share/doc/nextcloud Nothing. I am somewhat perplexed as to how a new user is supposed to proceed. Are there no docs? Could someone point me at a 'getting started - howto' applicable to this version in Mageia? Thanks
CC: (none) => zen25000
http://localhost/owncloud should be the way to go. This is a web app!
Status: NEW => ASSIGNED
Thanks - yes that helped :) I looked for running processes and services but found nothing with 'nextcloud' so was not expecting to be up, however http://<servername>/nextcloud does it.
@Barry: I wrote https://wiki.mageia.org/en/OwnCloud when i installed ownCloud. I use it just for family file sharing, and try to add info for other to use. Please add to it if you find something interesting :) ------------------------- @José : could you add the wiki link to the rpm description, for both OC9.1.6 and NC10 ? ------------------------- UPGRADE TEST I have never installed Nextcloud, yet, now i tried upgrading my owncloud 9.1.6: Quick dumb test, upgrade fails; 1) I installed this rpm, and owncloud package got removed 2) https://my.ser.ver.ip/owncloud/index.php/login : does not exist 3) https://my.ser.ver.ip/nextcloud/index.php/login works, but it is a fresh installation; ask to set admin pass and warns that SQLite will be used (slow), so it did not read the old configuration files. I guess it is because of the different name (owncloud/nextcloud) and that configs etc are in the old place. I think it is correct that the URI change from .../owncloud to .../nextcloud Do you have a plan about how the migration should be executed? Maybe admin should: 1) stop apache (and by that owncloud) 2) install nextcloud rpm (which also removes owncloud rpm) 3) rename folders and files from owncloud to nextcloud: /etc/httpd/conf/sites.d/owncloud.conf /etc/owncloud/ /usr/share/owncloud/ 4) check config files use correct naming in any references? 5) Hmm what about database (MariaDB) accepting nextcloud ? No problem? 6) start apache (runs nextcloud) When known, i can try it and write the procedure in our wiki. Another idea would be to have the rpm execute scripts, if method is as simple as renaming folders and files. A third idea is to recommend the script at https://nextcloud.com/migration/ instead. Admin downloads the script and it checks and alters everything needed including it downloads correct nextcloud version... Maybe that is a good idea as it is an officially proposed and easy method, but on the other hand some people like to know exactly what happens and like better to do all manually.
CC: (none) => fri
Well, I agree with your steps, please testproof them and add them to the wiki. Anyway, as hard as we try, a web app name change will keep hard to upgrade without manual steps. The migration script is a bad idea for us, because our package should not be overwritten by an external script.
OK I will try manual and report maybe tomorrow Why do the Nextcloud rpm contain both /etc/httpd/conf/sites.d/owncloud.conf /etc/httpd/conf/sites.d/nextcloud.conf
Answering myself: the nextcloud rpm files owncloud.conf is a symlink to nextcloud.conf -Probably some smart fallback catch we should leave as is = OK. Analysing what need to be done manually: (please correct/add anything, i am a casual hobby sysop...) First disable plugin apps, shut down server, take backup of everything owncloud like as below + data folder + database. And take extra backup of any config files mentioned below. (more detailed in wiki) 0) Uninstall owncloud rpm, and install nextcloud rpm (httpd is still off) 1) Owncloud used /etc/owncloud/config.php , now nextcloud use /etc/nextloud/config.php This is the core of configuration - check it carefully to not break i.e database connection. I copied the owncloud version of the file to be the nextcloud version, only changing one line in my case: overwrite.cli.url' => 'http://localhost/owncloud' where i changed "owncloud" to "nextcloud" 2) /etc/httpd/conf/sites.d/nextcloud.conf is identical to the old /etc/httpd/conf/sites.d/owncloud.conf from owncloud rpm - *except* that all instances of "owncloud" is replaced by "nextcloud". What I can see that is exactly what we want, and we let it use the new file from nextcloud rpm. (unless user need some tweak from default paths or other custom) In my simple case: no need to do anytning 3) Owncloud used /usr/share/owncloud/ , now nextcloud use /usr/share/nextcloud/ Here is the bulk of {own,next}cloud, including themes and settings which some users may want to move with some edits, and the apps folder and more... /.htaccess contain just the OC/NC version number. In my simple case: no need to do anytning 4) /usr/share/owncloud/data/ (linked from /var/lib/owncloud) - If you have not defined another place for your data, then it must be moved along! ( When following the advice to configure another data folder, we need not care about this. ) Then... start httpd, test nextcloud basically works, check logs, enable apps... That should work, i think, but when i start the server and go to login page it responds: " Downgrading is not supported and is likely to cause unpredictable issues (from 9.1.6.2 to 9.1.5.2) " How come it thinks it is version 9.1.5.2 ??
Hm i guess because OC 9.1 == NC 10, then OC 9.1.6.2 > NC 10.0.5.2 ? So we need a tad newer NC (or should have used OC 9.1.5, not .6) I added http://wiki.mageia.org/en/OwnCloud#Migrating_OC-.3ENC based on comment 7
(In reply to Morgan Leijström from comment #8) > Hm i guess because OC 9.1 == NC 10, then OC 9.1.6.2 > NC 10.0.5.2 ? > So we need a tad newer NC (or should have used OC 9.1.5, not .6) > No, it is an upstream bug as they say this is the good upgrade path. Maybe ask upstream? Sorry I have no time for now, but we may have to find which file contains this version and probably patch it to get a higher number.
Unfortunately the bug seem to be in the description of good migration path... " The latest Nextcloud 10.0.5 has same engine as Owncloud 9.1.5 Since Owncloud 9.1.6 has a newer engine, the process fails with message "Downloaded version is lower than installed version" " https://help.nextcloud.com/t/migration-from-owncloud-9-1-6-to-nextcloud-10-0-5-fails/13523/7 Next post have same problem as we, upgraded ownCloud and expacted to be able to migrate to NExtcloud - * the Nextcloud migration script * suggested that but of course failed... Currently still waiting for answer from developers when new version or workaround is expected. As described in posts a earlier in that thread, version can be tricked, and that worked for them, but that may result in mishaps. I also found this is not a new problem: same problem was discussed in the forum for a slightly earlier version, and they still have not corrected migration description, migration script, or software... :/ So: well known documentaiton bug, and the only real fix available for our upgrade path *now* i think is to withdraw OC 9.1.6 and instead get in a 9.1.5. Or we wait for NC 10.0.6. Personally i will try that version trick, but not today.
(Posting this comment also in bug 21064 as it concern both bugs) José, i saw you asked for removal of 9.1.6, in order to push 9.1.5, good :) Currently the packages owncloud and nextcloud do not conflict. - I think they should? I am about to reinstall 9.0.9 *fresh* and try updating from there.
Blocks: (none) => 20953
We better use and keep ownCloud 9.1.6; Tried OK a second reinstall 9.0.9 + upgrade to 9.1.6, then migrating to Nextcloud 10.0.5 with this trick: https://help.nextcloud.com/t/migration-from-owncloud-9-1-6-to-nextcloud-10-0-5-fails/13523/14 But there is a problem i have not solved yet It seem OK in web interface, but like many other users my clients fail to connect with message "error transferring" .../owncloud/owncloud/status.php - not found https://help.nextcloud.com/t/desktop-client-cannot-find-owncloud-status-php/4756 Any idea?
(In reply to Morgan Leijström from comment #12) > We better use and keep ownCloud 9.1.6; Tried OK a second reinstall 9.0.9 + > upgrade to 9.1.6, then migrating to Nextcloud 10.0.5 with this trick: > https://help.nextcloud.com/t/migration-from-owncloud-9-1-6-to-nextcloud-10-0- > 5-fails/13523/14 > So I should patch our 9.1.6 owncloud to announce as 9.1.5.1? Please indicate which file to patch, your link doe snot indicate a patch.
I think it is best to let it be as original to avoid any side effects. It is a simple manual edit in one of the steps i now have documented here: https://wiki.mageia.org/en/OwnCloud#Migrating_OC-.3ENC point 4b. From my simple testing, 9.1.6 is OK as is. But i have problem with NC 10.0.5 - why it fail with clients as comment 12 is beyond me. (i have only tested migration, not fresh install with it)
... i believe it is something more that need be done manually when migrating. As per the link in comment 12 other users have seen this, and there is a workaround i have not tried - and i do not want to try it as i dont understand how that works, and it include creating files we dont have. I t would be nice to find an explanation why, and a clean fix...
(In reply to Morgan Leijström from comment #15) > ... i believe it is something more that need be done manually when migrating. > As per the link in comment 12 other users have seen this, and there is a > workaround i have not tried - and i do not want to try it as i dont > understand how that works, and it include creating files we dont have. > I t would be nice to find an explanation why, and a clean fix... The purpose of a Mageia package is to prevent the user to have to do manual things. The well tested path is oc9.1.5->nc10.0.5 , and we don't need the 9.1.6 for anything. I will remove it and test if upgrade through this path works without any manual bug workaround.
OK, i will update the wiki to whatever we find working :)
(In reply to Morgan Leijström from comment #17) > OK, i will update the wiki to whatever we find working :) Nextcloud 10.0.5-3 is submitted. It moves the owncloud conf file if it is found from /etc/owncloud/ to /etc/nextcloud/. It also replaces inside it the default path http://localhost/owncloud if it was not changed. This should give a working nextcloud in MGA5, I have tested it with my own server. Now I think the wiki text can be much shorter, it has become too complex.
Great, José :) I will try migrating to it tomorrow. I presume /etc/owncloud/config.php will be copied to /etc/nextcloud/ ? One thing i noted with the old 10.0.5 after tricked upgrade from 9.1.6 was that it in admin page offers to update to 11.0.3! Should it not stay within 10.x ? Here I just finished a fresh install of 9.1.5, and error log is zero bytes also after some file syncing etc :) After migration test i plan to start fresh again on 9.0.9 and see if upgrade is clean to 9.1.5 - it was a minor thing to 9.1.6 Bug 21064#c6. I agree the wiki page is monstrous, but newbies like me (home/small office) need to have it explained and much linked info, how to access from internet, how to improve security and speed, etc. I try to keep it in some logical order and sections with internal links when useful. But YES it would be nice with a chapter that in short and concise commands install and configure it swiftly. Maybe placed as an appendix, but linked from close to top of page. Right now as appendix there is a command list example for reinstall - add a few details needed for initial install and very little text, maybe? Maybe i will later when all is settled, or you can if you like :)
Whats new in owncloud-9.1.5-2 ? (saw it now in pkgsubmit)
Quick test: updated 9.1.5-1 to 9.1.5-2, then NC10.0.5-3 Weird thing 1: Used drakrpm. Scaringly it did not say it uninstalled OC when it installed NC, but i proceeded anuway and now i notice OC is uninstalled. Did it get done by some postinstall script? Weird thing 2: Same error and warning as when i upgraded OC9.0.9 to 9.1.6 in an earlier test: https://bugs.mageia.org/show_bug.cgi?id=21064#c6 Problem: Like in comment 12: It seem OK in web interface, but like many other users my clients fail to connect with message "error transferring" .../owncloud/owncloud/status.php - not found https://help.nextcloud.com/t/desktop-client-cannot-find-owncloud-status-php/4756
(this time i did not do *anything* manually: just installed NC using drakrpm, then went to the web interface and started the update of applications :) Strange 1: that web UI did not *say* it update server (just apps) Strange 2: admin page offers to update to 11.0.3 (next *major* version! OC only offered x.x.minor versions here)
(In reply to Morgan Leijström from comment #21) > Weird thing 1: > Used drakrpm. Scaringly it did not say it uninstalled OC when it installed > NC, but i proceeded anuway and now i notice OC is uninstalled. Did it get > done by some postinstall script? It is normal : nextcloud is packaged as update to owncloud, so it replaces it. This is why I had to submit again 9.1.5 increasing release with the -2, as the -1 was aumtomagically removed from the mirrors. > > Weird thing 2: > Same error and warning as when i upgraded OC9.0.9 to 9.1.6 in an earlier > test: https://bugs.mageia.org/show_bug.cgi?id=21064#c6 > Forget it, it is an upstream little bug with no problem. I created manually this file in a previous upgrade, as indicated in Mageia Wiki, so I had no problem. > Problem: > Like in comment 12: It seem OK in web interface, but like many other users > my clients fail to connect with message "error transferring" > .../owncloud/owncloud/status.php - not found > https://help.nextcloud.com/t/desktop-client-cannot-find-owncloud-status-php/ > 4756 Is this a default install, using http://localhost/nextcloud url? If not, I think you have to edit the override path in /etc/nextcloud/config.php. But let's only test with default config, as if end users have done changes, they are supposed to know how to maintain the changes.
Thanks for the explanations :) This is after migration to Nextcloud from a default install of OC 9.1.5. - All clients should be able just continue using the old /owncloud/ URI wihtout needing reconfiguration on the client side.
(In reply to Morgan Leijström from comment #24) > This is after migration to Nextcloud from a default install of OC 9.1.5. > - All clients should be able just continue using the old /owncloud/ URI > wihtout needing reconfiguration on the client side. Sorry but I disagree here : as this is an url with the name of the app, and we change the app, we should change it. Furthermore, this allows to make easier upgrade to MGA6 where Nextcloud config files use the nextcloud path. This is easy to explain in the wiki, and this migration requires reading the wiki to know by which packages upgrade. Even if I believe we won't have much users reading it, unfortunaly they will just crash their install upgrading to MGA6 without preparing...
I kind of agree; the root of the problem problem is that part of the URL is made up of server software trade name. ("/owncloud/", originally) So when we migrate to another software, the question is wether to keep the tradition (in this case change the URL) or keep it (for uninterrupted use). Example: I have never seen companies change the home page URL because they upgrade from IIS to Apache... ;) The users problem is that when URL change, all users clients must reconfigure the sync client. All shared URL links must be edited. There are also implications on already established Federated cloud sharing (sharing between owncloud/nextcloud servers) and i guess also connections to other sharing (i.e Dropbox) But of course, if it is a fresh install of Nextxloud the URL should be /nextcloud/ and not /owncloud/ . So i guess is best to leave the packages as they are now... - However it would be *very* good if we can add a description to wiki as how to make all old connections to "/owncloud/" work :) That is above my own knowledge. Is this trick the correct way to do it?: https://help.nextcloud.com/t/desktop-client-cannot-find-owncloud-status-php/4756/8 How does that look when translated to Mageia?
(In reply to Morgan Leijström from comment #22) > Strange 2: admin page offers to update to 11.0.3 > (next *major* version! OC only offered x.x.minor versions here) Testing a fresh install of NC10.0.5-3: that works correctly: admin page say it is latest version (do not offer update to 11.x) So according to comment #22 this detail go wrong in migration.
Another thought on the URL name issue at migration (comment #25, #26): *IF* all links and clients are to be changed from owncloud to nextcloud, (the case with current packages and wiki) it would be logical that also the web page change to /nextcloud/ (not the case now)
* Forget comment 28; i was too tired, after migration web UI is nextcloud OK :) * I have put the concerns of comment 26 at https://wiki.mageia.org/en/OwnCloud#.3D_All_clients_.3D So admins are aware that migration as it is now (changed URL) breaks users syncing several ways.
It is funny that NC10 offer upgrade to NC11, if it was migrated from ownCloud 9.1, but not on fresh install. I just had some fun and let NC10 update itself to NC11. After that, NC11 offered to update to NC12, and that too worked :) ( Before it could update, i had to https://wiki.mageia.org/en/OwnCloud#Facilitating_auto_update )
For what NC10 decide what to update too, i now asked https://help.nextcloud.com/t/how-do-the-updater-decide-what-to-update-to/14692 -------------- About auto updater contra locked down files, i note the upstream recommendation have changed. Non locked down files is a less risk than a non updated owncloud/nextcloud. So the recommendation is to set file permission and ownership so users can use the updater. They have even removed the script they had before to set strong permissions. https://help.nextcloud.com/t/please-help-with-right-permissions-for-nc12/13780/4 Given the history we now have here at Mageia at being *far* behind in updating owncloud/nextcloud i think it would be a good idea to let our users use the updater - at least for minor release upgrade. Problem may be if the updater updates to a new major release, and user then accidentally updates using mageia rpm, but if we put all updates in backports that is supposed to not happen (unless mageia admin select to update from backport...) comments?
MIGRATION ERROR Test: have OC 9.1.5 running properly, set up completely as default: database=SQLite, and storage=/usr/share/owncloud/data After installing NC 10.0.5-3 go to http://myserver/nextcloud : that page is blank, and in php log see a lot of stack trace, DB connection errors. Investigating, i see /usr/share/owncloud/data was pointing to /var/lib/owncloud/ (link made by the Mageia package), and after migration one problem seem to be that /usr/share/nextcloud/data points to /var/lib/nextcloud/ which is empty, while data and SQLite database is still at old location /var/lib/owncloud/. It seems it did not help to copy to new location before starting nextcloud(apache) again, so maybe there is more to it? (or i did some mistake)
Created attachment 9449 [details] Script to enable auto updater - untested Pulling things together i think this script will make nextcloud autoupdater work; sets recommended rights and removes link to mageia cert. (In case someone wants to try) Note 1: it is untested !! Careful! (I have fouled up my test rig...) Note 2: for storage at /mnt/nextcloud/, can be edited Note 3: will probably work for owncloud, with edited path
(In reply to Morgan Leijström from comment #32) > MIGRATION ERROR > Test: have OC 9.1.5 running properly, set up completely as default: > database=SQLite, and storage=/usr/share/owncloud/data > > After installing NC 10.0.5-3 go to http://myserver/nextcloud : that page is > blank, and in php log see a lot of stack trace, DB connection errors. > > Investigating, i see /usr/share/owncloud/data was pointing to > /var/lib/owncloud/ (link made by the Mageia package), and after migration > one problem seem to be that /usr/share/nextcloud/data points to > /var/lib/nextcloud/ which is empty, while data and SQLite database is still > at old location /var/lib/owncloud/. > You are right, the default data path must also be changed in the config.php. Fixed in nextcloud-10.0.5-5.mga5 and tested here in a clean installation with default settings.
Tested again on i586, time to validate.
Keywords: (none) => validated_backportWhiteboard: (none) => MGA5-32-OK MGA5-64-OK
Good This can be achieved several ways. I want to note on the wiki how it is done. You mean that now the NC package install script detects if OC used /var/lib/owncloud/ (linked from /usr/share/owncloud/data) - and if so in config set pointer to /var/lib/owncloud/ ? Do it still create /var/lib/nextcloud/ ? --- Any idea of why NC after migration - but not after fresh install - say there is a newer version and wants to upgrade to 11 ?
(In reply to Morgan Leijström from comment #36) > Good > This can be achieved several ways. > I want to note on the wiki how it is done. > > You mean that now the NC package install script detects if OC used > /var/lib/owncloud/ (linked from /usr/share/owncloud/data) - and if so in > config set pointer to /var/lib/owncloud/ ? That's it. > > Do it still create /var/lib/nextcloud/ ? Yes. Even if it is useless in this case, the folder still exists. > Any idea of why NC after migration - but not after fresh install - say there > is a newer version and wants to upgrade to 11 ? No, but it is secondary as we have nextcloud 11 in MGA6.
Great :) Have you pinged sysadmin list about moving from testing? I will update the wiki on all relevant points when that is done.
nextcloud-10.0.5-5.mga5.noarch.rpm moved
Resolution: (none) => FIXEDStatus: ASSIGNED => RESOLVEDCC: (none) => tmb
(In reply to José Jorge from comment #37) > (In reply to Morgan Leijström from comment #36) > > Any idea of why NC after migration - but not after fresh install - say there > > is a newer version and wants to upgrade to 11 ? > > No, but it is secondary as we have nextcloud 11 in MGA6. Addendum: Possible problem is that maybe after upgrading the system to mga6, and thereby having NC11, that NC11 maybe suggest to upgrade itself to 12? ( As a test on mga5, i changed file permissions and let NC 10 update itself to 11, and after that it wanted, and succeeded to update to 12. (still on mga5) ) Not a real problem as we are supposed to make new rpms with new NC versions, and users are supposed to wait for them. However, IMO we should discuss changign strategy and let users update NC by means of the built in auto-updater, as recommended by upstream. THEN it will become important wether NC updater selects to update to next major or minor.
(In reply to Morgan Leijström from comment #40) > However, IMO we should discuss changign strategy and let users update NC by > means of the built in auto-updater, as recommended by upstream. THEN it > will become important wether NC updater selects to update to next major or > minor. This is not possible : allowing an user to add and delete files means garbage if he try to uninstall nextcloud : what files should be erased? What we could do is remove the warning about new version available, but I am not sure it is a good idea, as we should not hide facts to users.
I have just upgraded to MGA6 a system upgraded through all this versions, and it works nicely!
(In reply to José Jorge from comment #41) > (In reply to Morgan Leijström from comment #40) > > However, IMO we should discuss changign strategy and let users update NC by > > means of the built in auto-updater, as recommended by upstream. THEN it > > will become important wether NC updater selects to update to next major or > > minor. What i meant to stress, is that looking at historic fact we Mageia have been *very* lacking in providing updates :/ New upstream recommendation is to for common installations let the updater work. https://help.nextcloud.com/t/please-help-with-right-permissions-for-nc12/13780/4 Advanced users know to lock it down, change files rights and ownership, hack apache, database, and php configurations etc, in a variety of ways depending on situation. > This is not possible : allowing an user to add and delete files means > garbage if he try to uninstall nextcloud : what files should be erased? AFAIK the updater do not make additional files outside /share/usr/nextcloud I guess uninstalling rpm removes everything in there? A "politic" question however is if self updating applications is allowed in Mageia, especially on server. At least it do not perform updating without asking, and a concerned and literate admin sure knows (or knows how to read about) how to lock it down. > What we could do is remove the warning about new version available, but > I am not sure it is a good idea, as we should not hide facts to users. Agreed, leave the new version warning working - updating is very important for security. Problem have been that there have very rarely been a timely Mageia rpm to make the update! - which is my point. I suggest to leave it as is, and hope we can deliver updates -BUT also in wiki describe a way to enable the updater to work for them who wants that. In any case i have not found an answer to this: How to control the updater to look for next minor, or major version? ---------------------------------------------------- (In reply to José Jorge from comment #42) > I have just upgraded to MGA6 a system upgraded through all this versions, > and it works nicely! Great :) Just to clarify, what version did you start with, what db, and data location?
(In reply to Morgan Leijström from comment #43) > What i meant to stress, is that looking at historic fact we Mageia have been > *very* lacking in providing updates :/ No : we have provided all the security updates for the version x.y that was released with MGA5. Going to version x.y+1 is not a security update, this is why it was only provided as backport as there are API changes. > New upstream recommendation is to for common installations let the updater > work. > https://help.nextcloud.com/t/please-help-with-right-permissions-for-nc12/ > 13780/4 This is not for RPM setups, only manual installs. > AFAIK the updater do not make additional files outside /share/usr/nextcloud > > I guess uninstalling rpm removes everything in there? Wrong : there are often added/removed files. RPM works file by file, not but whole folders. And it does not remove files that were changed. > Just to clarify, what version did you start with, what db, and data location? It is a MGA4 system upgraded to MGA5, and now to MGA6 using owncloud backports.
Great test for update all way mga4 to mga6 ! Was it using default data location and database? __________________________________ Ah thanks for info on rpm behaviour :) - i really should read up on rpm... A user installing by rpm and then let NC update itself will face problem at least when upgrading mageia version then... *IF* a user choose that route, i guess a part of his method so solve it would be to make the rpm system "forget" it installed the NC rpm? (BTW it also mean users installing or updating apps in OC/NC face problems.) __________________________________ A week delay in providing an officially released update i think is OK, but there have been month delays even in minors, and even one gap of seven months delay. As the majors are rolling much faster than mageia releases, IMO we should also package new majors. Comparing file date in repo to https://owncloud.org/changelog/ we had: 8.0.5 a *month* after release 8.0.8 two days :) 8.0.9 five days :) 8.0.10 a *month* (we did not provide .11 but not important AFAICT, so OK) 8.0.12 same day! (we skipped 13 & 14, not very important updates AFAICT, so OK) 8.0.15 8 days before!? official release. Magic! :) Almost same day as 8.0.15 we in quick succession got *three* new major level updates: 8.1.10, 8.2.8, 9.0.5. - IMO Newer major in Mageia was at that time *long* overdue. Upgrades to new major reason is important for user to gain more/updated/corrected/externally-compatible functions and it would be a pity if Mageia rpm lack that so users need to change to manual or built-in update methods. - could potentially deter users from Mageia. I think the main reason we did not do this before was that it needed decision to put them in backports because of potential compatibility issues. 9.0.9 was next update we had, * seven months * !! since official update 9.0.6. Then a slight gap and we now released OC 9.1.5, and Nextcloud 10 in order to facilitate upgrade to mga6. That was about history. Lets try to keep delays short like we in most cases have :) __________________________________ Mageia 5 is said to be supported three more months (IIRC) - but NC 10 is already labeled "(unsupported!)" ! Doh! https://nextcloud.com/changelog/ ...So optimally we should package NC 11.0.3 also for mga5 ? (same as in mga6 release) (But i think we should never package NC12 in mga5.) For mga6 NC12 i think we should wait for a minor. (as usual there are some wrinkles in first major) ( Side note: I earlier this week tried a Nextcloud.org provided installer script at my ISP (shared hosting) and it for unknown reason installed NC11, then next hour suggested update to 12 which was sucessful minus the theming app (issue known) ) __________________________________ BTW, the client also lag behind, Bug 21015