On ബുധന് 30 നവംബര് 2016 06:01 വൈകു, Antonio Terceiro wrote: > I support your request, and urge people uploading libraries (or anything > with reverse dependencies, really) to test their reverse dependencies. > > *However*, looking at the diff between the latest ruby-grape-entity and > the one before that, I can easily see that there are not API changes. > Additionally, the only change documented as part of 0.6.0 itself is a > test suite refactoring, all other changes are bug fixes released in > 0.5.x releases. This tells us a few things: > > - SemVer, despite being a nice idea, should not to be taken to the extreme. > > - As I already said previously, you *cannot* assume all upstreams that > do not explicitly abide to follow SemVer are insane and will just > break their reverse dependencies at will. > > - The only reason why gitlab is "broken" by this, is because the > dependencies are declared too strictly. I strongly suggest leaving > breakage detection to actual functional tests. The problem is indeed lack of functional tests, I'm working on enabling all tests of gitlab. But until then its better to be careful about updates than fixing things after things break. Do you think people who break reverse dependencies without even giving time to test will help fix the problem? It can't really scale well with a big enough app like gitlab or diaspora. I'm already relaxing the dependencies than what upstream demands. But keeping it free for all is not something I can manage sanely. Are there people in the team who are willing to help out when updates break reverse dependencies? If not, I don't think this is a reasonable request. When you get a notice in advance there not much stress, but when you get notified is a breakage, it is stressful. When it happens so often its really hard. I have been working for years to get diaspora in shape, but I can't get a working version in stretch because jquery update broke diaspora. > Our upstreams can get away with such strict dependencies, because they > are able to pull whatrever version they want via bundler/rubygems.org, > and they have full central control on what versions will be pulled. We > in Debain can't get awayw with that without severely sacrificing our > sanity. > I'm not asking to follow upstream Gemfile.lock or even Gemfile blindly. Just time to test the update when it is a major version update or minor version of development library. When things break, it takes time to fix it, even if it is a trivial change.
Attachment:
signature.asc
Description: OpenPGP digital signature