Valentin Villenave <valen...@villenave.net> writes: > On 1/24/19, David Kastrup <d...@gnu.org> wrote: >> Development happens on Guile2, none on Guile1. > > That’s what I’m worried about: if we *were* to include guile1 as a git > submodule (effectively forking it, although I don’t imagine many Lily > devs are gonna be fiddling with its codebase), what are the > sustainability prospects in the long run? (e.g. when new major GCC / > glibc / whatever versions come around, breaking compatibility at some > point)
If you take a look at the Guile repository, the 1.8 branch already broke with Texinfo developments, possibly also gcc (don't remember) and Thien Thi Nguyen (I think) pushed a few fixes for that. Pretty sure that Thien Thi still uses Guile 1 for some application. At any rate, the kind of fixes needed in such cases are usually comparatively straightforward to come up with. > *Or* can we safely regard Guile v1 as "stable" and reliable on a > long-term perspective (much like you no longer need to worry about new > version of TeX coming out, or a very narrow number of other programs > deemed "frozen in perfection")? Not really. Non-catastropic bugs are definitely not getting fixed. > If so, sticking with v1 would mean better performance, greater > stability *and* acceptable sustainability (and besides as you noted, > even Guile v2 depends on very few devs, thus keeping the > getting-hit-by-a-bus factor fairly high anyway). And including Guile > v1 as a submodule could make life easier for users whose distros no > longer offer a guile1(-devel) package, couldn’t it? > > On an unrelated subject, am I the only one puzzled by the fact that, > although the global situation with Guile 2.0 was a mess, still they > went ahead and released new major versions, a.k.a. 2.2 and 2.4? Or is > it a year-based release cycle where the numbers don’t mean anything? > Very unusual within GNU programs. Who is "they"? How many "developer branch" commits do you see from anybody else but Andy Wingo that aren't forward-ported bug fixes from the more stable branches? The Guile compiler and VM is his playground for compiler technology. There is no discussion whatsoever regarding its development (and/or the unstable branches) on the Guile mailing lists, and commits are partly back-and-forth with stuff not working in between and complete recodings of stuff sometimes. The other "developers" clean up on the stable branches, cherry-picking into the unstable branch where necessary. There are definitely impressive benchmark improvements as long as you don't look at string handling too much and don't pass data into and out of Guile again and don't use the API. As a native Scheme environment rather than as an extension language needing to interface with C++ and other stuff, there are interesting things in there. It's just a bad match for what we have been doing with Guile and need to do with it. -- David Kastrup _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel