svn commit: r467193 - in head/www/gitlab: . files

[Philip M. Gollucci]

Welcome to ruby/rails.

On Fri, Apr 13, 2018 at 6:07 AM Alexey Dokuchaev <danfe at freebsd.org> wrote:

> On Fri, Apr 13, 2018 at 11:55:13AM +0200, Matthias Fechner wrote:
> > ...
> > To make tests for all features in Gitlab you will require many hours and
> > I'm not willing to do the work the gitlab team is doing already for us.
> > They provide us with clear instructions what version are tested and
> > should work.
> > To be 100% save we should use what is in the Gemfile.lock, but this
> > would really a major effort and I think to use what is in Gemfile
> > defined is relatively safe.
> > I remember only 2 cases where even the definition in the Gemfiles cause
> > gitlab to break. One was the upgrade of default_value_for from 3.0.3 to
> > 3.0.4.
>
> 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?
>
> ./danfe
> _______________________________________________
> svn-ports-all at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/svn-ports-all
> To unsubscribe, send any mail to "svn-ports-all-unsubscribe at freebsd.org"
>
-- 
---------------------------------------------------------------------------------
4096R/D21D2752
<http://pgp.mit.edu/pks/lookup?op=get&search=0xF699A450D21D2752> ECDF B597
B54B 7F92 753E  E0EA F699 A450 D21D 2752
Philip M. Gollucci (pgollucci at p6m7g8.com) c: 703.336.9354
Member,                           Apache Software Foundation
Committer,                        FreeBSD Foundation
Consultant,                       P6M7G8 Inc.
Director Cloud Technology,        Capital One

What doesn't kill us can only make us stronger;
Except it almost kills you.