Comment #3 on issue 1987 by [email protected]: Patch: Get rid of
most of the insane string-tunings API
http://code.google.com/p/lilypond/issues/detail?id=1987
We don't really have a process. Bigger fish to fry at the moment.
I definitely do not want a non-working master. If there's some fancy way
of telling git "treat these X patches as being together", particularly for
bisecting, then I guess it's ok to keep the code-patch, convert-ly patch,
and actual ly changes, as separate commits. But if there's any uncertainty
about that, then just screw it and lump them all into one huge commit.
Keeping the ability to easily do bisecting is more important then
functionally pure (side-effect-less) commits.
If we have multiple conversions in the same version number, which is a huge
pain of course, then you'll need to manually call
convert-ly --from-version 2.15.14 --to-version 2.15.15
or something like that.
I'll shove a release out right now (contradicting my claim that I'll always
merge dev/staging before a release, but I think you won't complain about it
this time) so we don't need to deal with that garbage.
_______________________________________________
bug-lilypond mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/bug-lilypond
