2009/8/14 Neil Puttock <[email protected]>: > 2009/8/12 Carl Sorensen <[email protected]>: > >> Redundant is OK by me. >> >> If I think of having a checklist for a developer to submit a change, it >> would include the following: >> >> 1) New or revised code. >> 2) convert-ly rule for revisions (new functions don't need convert-ly rule) >> 2) Regression tests that demonstrate the code, including revision of old >> regression tests and creation of new regression tests as necessary. >> 3) All Documentation/snippets files that use the revised code are converted >> and copied to Documentation/snippets/new. >> >> I think we should not have makelsr.py run except at release time. Here's >> why. >> >> Currently, devel release is 2.13.3. The current working git release is >> 2.13.4, but it's never been released. If I run makelsr.py, then all the >> snippets in Documentation/snippets will be updated by the current convert-ly >> rules to 2.13.4. >> >> Next week, Marc makes a change and adds a new convert-ly rule. >> >> But, since all of the snippets are now listed as 2.13.4, there is nothing to >> be done. > > This only applies to snippets in snippets/new, since the remaining > items will be converted from the LSR tarball (which defaults to the > stable version). > > TBH, I can't say I'm particularly concerned by this issue since the > onus would be on the person adding the new convert-ly rule to ensure > any snippet compilation problems are corrected (even if this has to be > done manually). If this turns out not to be the case, any breakages > should be caught by whoever's running makelsr.py on the LSR tarball. > >> >> So it seems to me that any changed snippets should be placed in >> Documentation/snippets/new and left there until a release is made, at which >> time all the conversion takes place to get them into the proper release >> shape, and applies all the rules necessary to convert from 2.13.3 to 2.13.4. >> >> Does this make any sense, or am I all wet? >> >> Thanks, >> >> Carl >> >
_______________________________________________ lilypond-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/lilypond-devel
