Date: Fri, 13 Apr 2018 16:27:38 +0200 From: Matthias Fechner <idefix@fechner.net> To: Alexey Dokuchaev <danfe@FreeBSD.org> Cc: Sunpoet Po-Chuan Hsieh <sunpoet@freebsd.org>, ports-committers@freebsd.org, svn-ports-all@freebsd.org, svn-ports-head@freebsd.org Subject: Re: svn commit: r467193 - in head/www/gitlab: . files Message-ID: <020dce99-1b72-3db3-5105-2acd6ad4a228@fechner.net> In-Reply-To: <20180413100736.GA32041@FreeBSD.org> References: <201804121833.w3CIXtgW077267@repo.freebsd.org> <e1a55c7b-1ad1-36c8-ec3d-f806702feed5@fechner.net> <CAMHz58RD9rtyqBLV6nsZ2naOvGRiO7PDPAGWZ8Vemnz-g1J6cw@mail.gmail.com> <431aaec9-51c2-c0c9-7a1f-2f29f79edb5d@fechner.net> <20180413100736.GA32041@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Dear Alexey, Am 13.04.2018 um 12:07 schrieb Alexey Dokuchaev: > I don't quite understand how/why would anyone in their right mind write= > software than breaks when one of its dependencies have *minor* version > bump? Is this specific to Gitlab, or the nature of Gemfiles is really > that broken? this is not the case. Gitlab defined the dependency with 'default_value_for', '~> 3.0.0'. This means minimum version >=3D 3.0.0 but not higher than 3.0.x. So 3.0.15 or 3.0.80 is fine, but not 3.1.0 as this is seen as major upgrade that will not work anymore. And that is exactly what happens. The Gemfile was modified by a not approved patch to use another major version of this dependency. I think the risk that you break it now is very high. The gitlab developers have a reason why they defined ~> 3.0.0 and not ~> 3.0. The problem with FreeBSD ports is (if I'm wrong please correct me), you cannot define such a ranges like with ~>, but FreeBSD can only do very simple checks like > or >=3D. Sry for the long answer, but hopefully everyone interested in does now know what ~> 3.0.0, ~> 3.0 and ~> 3.0.2 means. I have here really only one wish for gitlab, do not modify the Gemfile if you have not really tested it very carefully. If the Gemfile is modified, it is the responsibility of the person that patches a file to make sure to not break the port. And it is not the task for the maintainer of the port to test if an unasked patch will not break the port. Gru=C3=9F Matthias --=20 "Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the universe trying to produce bigger and better idiots. So far, the universe is winning." -- Rich Cook
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?020dce99-1b72-3db3-5105-2acd6ad4a228>