<div dir="ltr"><div>Yes, there was a proposal to follow how it's done in Elm: Cabal PVP compliance checker [1]. There's also an outdated check-pvp package [2] but it requires base < 4.7.<br><br></div>Michal<br><div><br>[1] <a href="http://blog.johantibell.com/2015/03/google-summer-of-code-2015-project-ideas.html">http://blog.johantibell.com/2015/03/google-summer-of-code-2015-project-ideas.html</a><br>[2] <a href="http://hackage.haskell.org/package/check-pvp">http://hackage.haskell.org/package/check-pvp</a><br><br><div class="gmail_extra"><div class="gmail_quote">On Thu, Apr 9, 2015 at 1:37 PM, Alexey Shmalko <span dir="ltr"><<a href="mailto:rasen.dubi@gmail.com" target="_blank">rasen.dubi@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">As far as I understand PVP, you can't rely on any C. Only which are greater-equal to one you tested your package with. It's because minor version can introduce changes that are not forward-compatible.<div><br></div><div>So basically, PVP is Qt versioning scheme with two first numbers being Major, third one being Minor and the rest is Patch.</div><div><br></div><div>If such convention already exists, what's left is to invent the way to enforce it.</div></div><div class=""><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Apr 9, 2015 at 8:28 PM, Michal Antkiewicz <span dir="ltr"><<a href="mailto:mantkiew@gsd.uwaterloo.ca" target="_blank">mantkiew@gsd.uwaterloo.ca</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div><div><div>Well if the package X you depend on adheres to PVP [1]<br><br></div>then you depend on it like this to allow newer minor versions:<br><br></div>x == A.B.*<br><br></div>where<br><br>"<i>A.B</i> is known as the <i>major</i> version number, and <i>C</i> the <i>minor</i> version number."<br><br></div>If only every package maintainer adhered to this, we'd be in much better shape.<br><div><div><div><div><div><br>Michal<br><br>[1] <a href="https://wiki.haskell.org/Package_versioning_policy" target="_blank">https://wiki.haskell.org/Package_versioning_policy</a><br></div></div></div></div></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Apr 9, 2015 at 1:24 PM, Alexey Shmalko <span dir="ltr"><<a href="mailto:rasen.dubi@gmail.com" target="_blank">rasen.dubi@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">I really love Qt versioning scheme when applied to compatibility [1].<div><br></div><div>Given version is Major.Minor.Patch:<br><div><br></div><div><div>Major releases may break backwards binary and source compatibility, although source compatibility may be maintained.</div><div>Minor releases are backwards binary and source compatible.</div><div>Patch releases are both backwards and forwards binary and source compatible.</div><div><br></div><div>So that you know your package will work with any Qt version that has the same major version and minor version is greater-equal to the one you developed your package with. It would be really great if everyone followed this scheme.</div><div><br></div><div>As a drawback I can note that this requires strict discipline from a library developer. It's also harder to get binary compatibility right for Haskell because of cross-module optimization GHC does.</div><div><br></div><div>[1] <a href="https://wiki.qt.io/Qt-Version-Compatibility" target="_blank">https://wiki.qt.io/Qt-Version-Compatibility</a></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div>On Thu, Apr 9, 2015 at 7:44 PM, Patrick Redmond <span dir="ltr"><<a href="mailto:plredmond@gmail.com" target="_blank">plredmond@gmail.com</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div>Since learning Haskell I've had the pleasure of finding my way out of a cabal hell or two. I've developed some knowledge to cope with it [1], but mostly concluded that if I can avoid burdening my projects with dependencies that have many of their own dependencies, then cabal hell can be averted. This puts somewhat of a damper on the joy of haskell's composability.<div><br></div><div>With the new release of GHC I've observed a flurry of discussion on haskell mailing lists and from Linux distro maintainers about all the fixing and patching required to keep the haskell ecosystem going.</div><div><br></div><div>Meanwhile I've learned other languages and used other tools that don't seem to have this problem that haskell does. For example, in the elm-lang community the package management tool enforces strict api-versioning, and in the clojure ecosystem people talk about "repeatability" and achieve it by using mostly exact-version requirements, even including the language (the language version is a dependency of a project, rather than a constraint of the environment).</div><div></div><div><br></div><div>I guess I'm wondering why we don't try something simpler to solve the haskell cabal hell problem. How about using minimum version dependencies only, not ranges, since we can't accurately guess about the future compatibility of our projects. How about automatic api-versioning of our projects to give the version numbers some rigid semantics with regard to package compatibility?</div><div><div><br></div><div>[1] <a href="http://f06code.com/post/90205977959/cabal-usage-notes" target="_blank">http://f06code.com/post/90205977959/cabal-usage-notes</a></div></div>
<br></div></div>_______________________________________________<br>
Haskell-Cafe mailing list<br>
<a href="mailto:Haskell-Cafe@haskell.org" target="_blank">Haskell-Cafe@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</a><br>
<br></blockquote></div><br></div>
<br>_______________________________________________<br>
Haskell-Cafe mailing list<br>
<a href="mailto:Haskell-Cafe@haskell.org" target="_blank">Haskell-Cafe@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</a><br>
<br></blockquote></div><br></div></div></div></div>
</blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
Haskell-Cafe mailing list<br>
<a href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</a><br>
<br></blockquote></div><br></div></div></div>