Hi, (Sorry about the strange reply style.)
On Sun, Aug 23, 2020 at 1:58 PM Jonas Hahnfeld <hah...@hahnjo.de> wrote: > I'd like to ask what it would take in principle to branch stable/2.22 > and what others think about this. > > Personally I'm convinced that creating the branch and only picking bug > fixes from master is the only guaranteed way to stabilize. Now you > might say that there were only few unstable releases (AFAICT there was > 2.19.65 before branching stable/2.20). However, I think there are > already quite some user-facing changes and also the switch to Python 3. > With Python 2.x being EOL since January, it's only a matter of time > until Linux distributions and BSDs want to drop that, and it would be > unfortunate if that put a (temporary) end to providing LilyPond for > their users. If we had release candidates or even a stable version > until then, it would definitely help. Maybe we could try to release 2.20.1 with Python 3? > The same can of course happen with Guile, but that situation has been > going on for years. Furthermore, it's at least possible to compile and > use current master with Guile 2.x, even if slower. In my understanding, > things are getting better but properly integrating byte compilation is > still a good amount of work that nobody could give a deadline on. > > WDYT? [Han-Wen] I think that both Python 3 support and usable (if imperfect) GUILE 2 support is a strong argument for releasing a new stable version soon. Why Guile 2? If it's still imperfect and slower, we don't want to make it the default in the binaries at lilypond.org, do we? So how will the situation be different from 2.20? Sorry, I must be missing something obvious here... I don't understand you. At any rate, Python 3 support is great, but the scripts are fragile at the moment. This is clear from the tracker and the bug-lilypond list. Our Python scripts still need fixes in the way we distribute them, plus encoding-related issues (I'm planning on tackling the latter point in a short period at the end of August, but who knows what that will reveal). [Han-Wen] I've been working on the build system (obviously), with in the back of my mind having a build that is no longer recursive, but that work could be paused for a bit while we prepare for releasing a 2.22. Is there a list of problems in the current master that have to be resolved? Problems are basically popping every week (e.g., info installation, translation tools, etc.). You're fixing them every week, which is really great, but before creating a release branch that is devoted to stability, I think we need a couple months to see what new problems appear, don't we? We have unstable releases to publish new features and get testing. In my opinion, stable releases should really focus on stability, there's no need to rush because of Python 3 and Guile 2. At least four areas are currently under flux: Python scripts, the build system, Guile 2 support, and fonts (Owen's project), and I don't see that master is coming any close to stability. I think we are better with focusing on these areas as long as they still require substantial attention, so as to get a stable and nice LilyPond 2.22 in a timely manner. You derecursify the build, David completes his stack of rather extensive purportive changes, Owen merges the GSoC branch, etc., and only then it'll be time to care about LilyPond 2.22. Am Sonntag, den 23.08.2020, 14:59 +0200 schrieb David Kastrup: > > I'd like to ask what it would take in principle to branch stable/2.22 > > and what others think about this. > I don't see that this is a good point of time. > There has been an influx of badly tested changes to the build system and > directory setup and the web pages that has to stabilise and result in a > workable version of LilyPond. I don't see the point in branching a > "stable" branch if there is so much in a destabilised state: you'd have > to cherry-pick loads of stuff from the unstable branch as it comes in. [Jonas] I fully agree ... and so do I (for what my opinion's worth, really) ... [Jonas] and I should have been more clear that I don't expect the branch to happen in the next week. The point was to find out what it would take because just waiting for some unspoken condition to become true is not exactly going to happen without some effort. What about scheduling the release? While I do know that "Grass doesn't grow faster when you pull on it.", I would definitely like having a defined point in time where the stable release is to happen, so that everyone can focus on bug fixes before it happens. Sure, we aren't going to get agreement in a second about the date (even if not more precise than a month), but to me, having this talk now is preferable so as to give LilyPond development a tempo. To say it with other words, we've got a score to play; arguing about the tempo is better than starting the piece with different tempi. As sort of a shot in the dark, how about planning the 2.22 release for May 2021, for example? Cheers, Jean