Branch v17, possible new branch "dynamic version" and PHP 7.3?

[chilinux]

The master branch is now upgraded to NextCloud v18. Did you want to make a v17 branch accordingly?

I also wanted to ask if there is any interest in the nextcloud.spec dynamically being generated by a bash / php-cli based script?

The idea would be that the script would automatically pull (and parse) what the latest supported major versions of Nextcloud are. It would then offer the user the ability to choose to generate a RPM spec file using the major version they specify at the command line. Instead of needing to update git on every NextCloud release, the script should automatically take care of the most common scenario were the spec file just needs to have the latest version without any other modification.

Lastly, SCL now seems to be offering PHP 7.3. NextCloud v18 is not end of life until January 2021 which is a month after the PHP 7.2 end of support on November 30, 2020. Would switching PHP versions now early on in the v18 lifecycle be preferable? Or did you want to wait until closer to the PHP 7.2 EoL at the end of the year?

Thanks

[gsanchietti]

Did you want to make a v17 branch accordingly?

Done.

The idea would be that the script would automatically pull (and parse) what the latest supported major versions of Nextcloud are. It would then offer the user the ability to choose to generate a RPM spec file using the major version they specify at the command line. Instead of needing to update git on every NextCloud release, the script should automatically take care of the most common scenario were the spec file just needs to have the latest version without any other modification.

I like the idea, but instead of a script that generates the spec, I would prefer a scheduled job which creates the pull request with the update. Then we could check the PR and apply it.

Or did you want to wait until closer to the PHP 7.2 EoL at the end of the year?

I would wait PHP 7.2 EOL. You know, programmers are lazy :)

Also just a personal note.
I've been at FOSDEM this week, and as far as I understand nobody in Nextcloud is really interested in these packages nowadays, since most of the users use snap, docker or pre-built machines. I'm wondering if maintaining the RPM is worth the effort 🤔

[chilinux]

I like the idea, but instead of a script that generates the spec, I would prefer a scheduled job which creates the pull request with the update. Then we could check the PR and apply it.

Keeping it completely on the backend would defeat part of what I was trying to achieve which is to remove the latency for checking the PR and also expecting the user to always do a recent pull themselves each time before building.

I would wait PHP 7.2 EOL. You know, programmers are lazy :)

I know, system administrators are as well. I am fine with that but just wanted to get on the same page as you for the road map.

Also just a personal note. I've been at FOSDEM this week, and as far as I understand nobody in Nextcloud is really interested in these packages nowadays, since most of the users use snap, docker or pre-built machines. I'm wondering if maintaining the RPM is worth the effort thinking

I noticed a lot of good talks on youtube from FOSDEM. I should probably take a look at them sometime.

As to why I think it would still be worth the effort to maintain a RPM might better be done via email instead of through github. At the very least I would like to provide a script that better streamlines using a Docker CE based solution for a novice CentOS user and makes it easier to migrate from the RPM.

[gsanchietti]

Since Nextcloud is not interested in maintaining RPM nor DEB packages, I'm going to abandon such effort.
I will create some custom RPM just of NethServer distro (see NethServer/nethserver-nextcloud#73)

@chilinux @alepolidori would you like to became the maintainer of the repository?
If so, please ask @jospoortvliet ;)