"Phil Holmes" <m...@philholmes.net> writes: > From: "John Mandereau" <john.mander...@gmail.com> >> >> I'm not completely happy with the current set of instructions on page >> "Minor release checklist", even for a release from master branch: >> merging master into an existing release/unstable branch may import >> undesired changes from the latter branch. > > I understand this would be possible if someone puched a change to > release/unstable without it going through staging/master. However, in > the life of LilyPond I don't think it has ever happened.
It certainly has happened since the release/unstable branch is quite older than the staging branch, but we haven't ever made unstable releases at least in the time I have been involved actively enough to notice that were not pretty much straight taken from master. > so may not be worth being too concerned about? I think so. It's conceivable for emergency releases where one release was so bad that we need immediate replacement. But I don't think we did those. > So - to summarise - you're suggesting not building from stable/2.20 > but from a new (temporary) branch, and therefore updating the new > branch rather than pushing any changes to release/2.20 before a build? > That sounds very sensible. The current setup for stable while in the prerelease stage (where the stable branch has taken on a life separate from master) is a bit ad-hoc. That stage should last a lot shorter than it already does. Our unstable releases or final stable releases are more straightforward. -- David Kastrup _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
