I've also been bitten by this issue with 4.03. Specifically, Merlin took about 2 weeks post-release to be ready, making it much harder to program in 4.03, and I had a dependency chain that needed OASIS to build.
I don't think we can avoid having a specialized pre-release period for getting the packages up and running. I noticed many of these breakages before 4.03 was released, but package authors aren't responsive to a pre-release breakage. It's important to prioritize though -- those packages that have the most reverse-dependencies and the ones that are most popular, should be the highest priorities to fix. OPAM has this info, and just as the https://opam.ocaml.org/packages/index-popularity.html page shows the most popular packages, I think it should pull their build-state for the latest OCAML release version and highlight them if they're broken. Speaking of which, it would be nice if the opam webpage also had a 'sort by reverse dependencies' list. One schedule that perhaps could work would be to have a pre-platform-release month. Within this month, package authors would have the first 2 weeks to fix their packages. After these 2 weeks, there would be a rallying cry to fix packages sorted by priority (highest reverse-dependencies & highest popularity), and the entire community would be mobilized to help in the effort. Once a "sufficient" number of the highest priority packages are fixed, the full release can take place, but the work can be ongoing. -Yotam On Thu, Jun 30, 2016 at 9:17 AM, Daniel Bünzli <[email protected]> wrote: > Le jeudi, 30 juin 2016 à 13:58, Fabrice Le Fessant a écrit : >> You can ask this kind of diligence from sub-contractors, not from >> open-source contributors, especially when a package is maintained only by >> one developer on his/her sparetime. > > I'm not asking anything. I'm only commenting on the fact that Sylvain said > that the time response was not long. It wasn't indeed but release time is not > the right time point to consider. The right time point to consider is the rc > betas. > >> Or if you think these components are key to the infrastructure, why not move >> their development to github.com/ocaml/ (http://github.com/ocaml/) with a >> larger team of maintainers, as it was done for OPAM ? > > I personally don't care as I'm not interested in oasis. But many other > programmer seem to use it so it's a pre-requesite for them to be able to work > in a given release and if this doesn't happen during the betas then we get > less testing. Regarding oasis' development model I'll let users of oasis > decide on what is best them. > > Best, > > Daniel > _______________________________________________ > Platform mailing list > [email protected] > http://lists.ocaml.org/listinfo/platform _______________________________________________ Platform mailing list [email protected] http://lists.ocaml.org/listinfo/platform
