[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
http://code.google.com/p/lilypond/issues/detail?id=1987
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???
Cheers,
Reinhold
- Issue 1987 in lilypond: Patch: Get rid of most of the insane string-tunings API, lilypond, 2011/10/23
- Re: Issue 1987 in lilypond: Patch: Get rid of most of the insane string-tunings API, lilypond, 2011/10/23
- Re: Issue 1987 in lilypond: Patch: Get rid of most of the insane string-tunings API, lilypond, 2011/10/24
- Re: Issue 1987 in lilypond: Patch: Get rid of most of the insane string-tunings API, lilypond, 2011/10/24
- Re: Issue 1987 in lilypond: Patch: Get rid of most of the insane string-tunings API, lilypond, 2011/10/24
- Re: Issue 1987 in lilypond: Patch: Get rid of most of the insane string-tunings API,
lilypond <=
- Re: Issue 1987 in lilypond: Patch: Get rid of most of the insane string-tunings API, lilypond, 2011/10/24
- Re: Issue 1987 in lilypond: Patch: Get rid of most of the insane string-tunings API, lilypond, 2011/10/24
- Re: Issue 1987 in lilypond: Patch: Get rid of most of the insane string-tunings API, lilypond, 2011/10/24
- Re: Issue 1987 in lilypond: Patch: Get rid of most of the insane string-tunings API, lilypond, 2011/10/25
- Re: Issue 1987 in lilypond: Patch: Get rid of most of the insane string-tunings API, lilypond, 2011/10/25
- Re: Issue 1987 in lilypond: Patch: Get rid of most of the insane string-tunings API, lilypond, 2011/10/25
- Re: Issue 1987 in lilypond: Patch: Get rid of most of the insane string-tunings API, lilypond, 2011/10/26
- Re: Issue 1987 in lilypond: Patch: Get rid of most of the insane string-tunings API, lilypond, 2011/10/26
- Re: Issue 1987 in lilypond: Patch: Get rid of most of the insane string-tunings API, lilypond, 2011/10/26