On 12.10.20 12:09, Petr Pisar wrote:
RHEL releases a minor version every six months. And as I remember,
allows breaking upgrades at each new RHEL release. Thus technically, it's
possible to rebase the package every year without getting into conflict with
packaging guidelines. On the other hand, I'm not sure whether the users know
it and expect it.
OK, that might work - somehow I remembered the minor versions being
released more rarely.
You could package each new incompatible version into a separate
and keep maintaining only the latest one. This way the users could switch
to the newer stream whenever they feel comfortable. If they slip switching
to the latest stream, then can migrate any later by hopping through all the
intermediary streams up to the latest one. That could be even automated by
At As Nick Howitt pointed out, NC can be modified to skip the version
check, so maybe the hopping isn't even necessary. Still, if the old
streams remain available ... intriguing possibilities.
There is a downside of the modules: There is no mechanism for tracking the
latest stream automatically. DNF team is willing to implement the mechanism,
but so far it's only a conception. It's also dubious whether the new mechanism
would be ported back to RHEL 8. So far users have to switch the streams
I was thinking of offering a nextcloud-stable or -latest stream that
simply follows upstream release channel (i.e. N+1.0 replaces N.x, even
if N is still supported and receiving updates) in addition
tonextcloud-<version>. Or have a normal (ursine?) package for that. That
way users can choose between an automatically updating or version-stable
Nextcloud, and whatever they choose, they know what they're in for.