Re: Future tag names for releases
On Wed, Mar 16, 2022 at 9:57 PM Jonas Hahnfeld via Discussions on LilyPond development wrote: > while trying to round up the procedure for future releases, I've come > across one point that I don't particularly like, and that are the tag > names in the git repository. For example, the latest version 2.23.6 is > tagged as release/2.23.6-1, which leads to the quite ugly and long link > https://gitlab.com/lilypond/lilypond/-/releases/release%252F2.23.6-1 > because the forward slash needs to be URL-encoded. I don't care much, but if we paint the bikeshed, can we prefix the version with a non-digit, eg. refs/tags/v2.23.6 the leading digit always has me do a double take to check it's not a number of a hex commit hash. -- Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
Re: Future tag names for releases
On Mar 16, 2022, at 17:04, Jean Abou Samra wrote: > > Le 16/03/2022 à 21:57, Jonas Hahnfeld via Discussions on LilyPond development > a écrit : >> >> ... >> would drop the superfluous "release/" prefix (probably still stemming >> from CVS times?) and the "-1" suffix for the buildnumber, which was >> essentially unused since 2.19.37 and doesn't have an equivalent in the >> new system. >> >> Objections, thoughts? > > > +1 from me. > > Jean No objection. — Dan
Re: Future tag names for releases
Le 16/03/2022 à 21:57, Jonas Hahnfeld via Discussions on LilyPond development a écrit : Hi all, while trying to round up the procedure for future releases, I've come across one point that I don't particularly like, and that are the tag names in the git repository. For example, the latest version 2.23.6 is tagged as release/2.23.6-1, which leads to the quite ugly and long link https://gitlab.com/lilypond/lilypond/-/releases/release%252F2.23.6-1 because the forward slash needs to be URL-encoded. Right now, these tag names are "mandated" by GUB and also used for the binaries. But as we move away from that system, we might as well change the template to something shorter, such as only "2.23.7" with the quite nice URL https://gitlab.com/lilypond/lilypond/-/releases/2.23.7 This would drop the superfluous "release/" prefix (probably still stemming from CVS times?) and the "-1" suffix for the buildnumber, which was essentially unused since 2.19.37 and doesn't have an equivalent in the new system. Objections, thoughts? +1 from me. Jean
Future tag names for releases
Hi all, while trying to round up the procedure for future releases, I've come across one point that I don't particularly like, and that are the tag names in the git repository. For example, the latest version 2.23.6 is tagged as release/2.23.6-1, which leads to the quite ugly and long link https://gitlab.com/lilypond/lilypond/-/releases/release%252F2.23.6-1 because the forward slash needs to be URL-encoded. Right now, these tag names are "mandated" by GUB and also used for the binaries. But as we move away from that system, we might as well change the template to something shorter, such as only "2.23.7" with the quite nice URL https://gitlab.com/lilypond/lilypond/-/releases/2.23.7 This would drop the superfluous "release/" prefix (probably still stemming from CVS times?) and the "-1" suffix for the buildnumber, which was essentially unused since 2.19.37 and doesn't have an equivalent in the new system. Objections, thoughts? Jonas signature.asc Description: This is a digitally signed message part
Re: Blockers for Guile 2.2
Le 19/02/2022 à 17:57, Jonas Hahnfeld a écrit : Hi all, I'd like to discuss what are considered blocker issues for a switch to Guile 2.2. After the release of 2.23.6, there were reports of major problems on Windows, namely that the binaries were broken when extracted with the Windows Explorer (#6281) and that file names with special characters didn't work (#6282). I think I found solutions for both of them, either already merged (!1194 for #6281) or in review (!1219 for #6282). The second large topic was performance of the binaries with Guile 2.2, which we know will be worse without compiled bytecode. In https://lists.gnu.org/archive/html/lilypond-devel/2022-02/msg00099.html Jean writes [Guile bytecode for LilyPond's .scm files] should be added eventually before we make a full switch. I don't fully agree and think that bytecode compilation shouldn't block the switch. In my opinion, it would be fine for the next development releases to be somewhat slower if that results in Guile 2.2 being available sooner. The trade-off will be different for a stable release where we certainly want LilyPond to be as fast as possible. That was the main reason why I posted about GUILE_AUTO_COMPILE last year, to have a fallback ready in case we can't get proper compilation working (and showing that the compiled bytecode gives very similar performance to Guile 1.8, of course). What do you think? Are there are other issues that need to be taken into account? Jonas Pasting this link for future reference: https://gitlab.com/lilypond/lilypond/-/merge_requests/1250 Jean
