[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Issue 1185 in lilypond: version numbers for large new features
From: |
lilypond |
Subject: |
Issue 1185 in lilypond: version numbers for large new features |
Date: |
Wed, 14 Jul 2010 09:36:24 +0000 |
Status: Accepted
Owner: ----
Labels: Type-Other Priority-High Maintainability
New issue 1185 by percival.music.ca: version numbers for large new features
http://code.google.com/p/lilypond/issues/detail?id=1185
New features require specific version numbers; new features with syntax
changes require even more fussiness about version numbers. If we have a
devel release every two weeks, there's a lot of "chasing version numbers"
going on.
The problem is the convert-ly rule for the changed syntax -- if he
wrote the rule for 2.13.25 but doesn't merge until 2.13.29, then
convert-ly will have an incorrect version. This also applies to
the version number in input/regression/ files.
I'm not entirely certain why he's changing the version number in
Documentation/ files, since those should be updated by running
convert-ly on them (followed by any manual changes that are
necessary)... but here we're in uncharted and definitely
disorganized territory.
The solution might be as simple as an xargs | sed thing. Or maybe
something complicated involving git format-patch, seds, git am, branches,
etc.
Anyway, it would be good if somebody seriously looked into this.
- Issue 1185 in lilypond: version numbers for large new features,
lilypond <=