[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Issue 1987 in lilypond: Patch: Get rid of most of the insane string-

From: lilypond
Subject: Re: Issue 1987 in lilypond: Patch: Get rid of most of the insane string-tunings API
Date: Mon, 24 Oct 2011 09:56:53 +0000

Comment #5 on issue 1987 by address@hidden: Patch: Get rid of most of the insane string-tunings API

Am Monday, 24. October 2011, 08:38:09 schrieb address@hidden:
I still don't quite get the process regarding convert-ly rules. Do I check
in the results of the convert-ly run as a separate commit?  For one thing,
that would make one commit deliver a non-working master.  Do I check in
both unconverted and converted as a single commit of a 2-commit branch?

It doesn't really matter... For git bisect it might be more useful to have them as one commit (or as a 2-commit non-ff merged branch).

But the conversion should only be done when bumping the version number at
the same time, right?

No, you you should do it immediately (the syntax change is in master).
The way version numbers work is that when a release is done, the version number in VERSION is increased. The VERSION_DEVEL is the last released version, the MAJOR_VERSION.MINOR_VERSION.PATCH_LEVEL is the version of the NEXT release, which should be used in a \version statements and all convert-ly rules.

It's true that by this we have a small window of git commits (all commits between the previous release and the syntax change), where the convert-ly rule would not produce working results. But that's not a problem, because 1) No user will ever use one of those git commits, even developers hardly will ever work with a previous git commit after having worked on master. 2) The convert-ly of that git commit will not yet include the syntax change, so it will also not upgrade to a not-yet-working syntax

On the other hand, there might be a problem if we have two syntax changes, because the first will already update the \version statements to the latest version, so a second syntax change during a patch-level release will not change those files any more...

Hmm, good question how to handle this???


reply via email to

[Prev in Thread] Current Thread [Next in Thread]