Problem: Gemfile has too tight version requirements which should instead be solved by Gemfile.lock

[pravi]

We should follow SemVer.org when declaring dependency requirements to allow newer semver compliant versions to satisfy dependencies. For people depending on Gemfile.lock, this does not change much, but it helps in native Debian package where gems are updates globally. Currently this is achieved by maintaining a patch that relaxes the versions. https://salsa.debian.org/ruby-team/diaspora/-/blob/master/debian/patches/relax-dependencies.patch

[weex]

If I understand correctly the problem with how it's handled now is that we're locking versions more tightly than necessary which can have the effect of pinning the installed version on a system (if ruby-team didn't maintain the above patch) or making it necessary to use some kind of ruby virtual environment.

[pravi]

Yes, the locking is more tighter than what is normally user in other apps (for example gitlab). For example, take json-shema, which is locked to '2.8.1', if we update the version to 2.8.2, this will not satisfy diaspora even if it is just a bug fix.

"~> 2.8", ">= 2.8.1" is sufficient for semver compliant libraries.

[pravi]

We prefer to maintain one version of json-schema and keep multiple versions only in rare cases as last resort (for example when major versions change or has a lot of work to make a single version work). This helps in reduced effort to maintain libraries.

[Mansh05]

@pravi, This is nice but since we do sync with the upstream, is this a big problem? Securities patches are nice but will this effect the whole dev cycle? diaspora is an old project so why not raise this in the upstream repo which will benefit a lot of other forked instances as well? What do you say?