Our 2.3.0alpha1 tar was not complete enough to make a Windows build. I made the mistake of not sending a tar to Uwe earlier to see if it was complete, before I made the official tag and push of the alpha1 release. I can reduce the chance of a similar issue coming up by just sending a tar to Uwe and Stephan e.g. a week before to check that everything is looking OK. But even in this case, there would be a risk due to commits after a week before. I wonder if the following is a way to address this potential issue in a more robust way.
There are two goals: 1. Close master branch for as little time as possible. 2. All binaries must be built from the official tar ball. In order to achieve these two goals, I think that we could do the following: 1. Do all of the commits *before* the "This is LyX 2.3.0beta1" commit. Push those to master 2. Create a new branch for the pre-release: git checkout -b 2.3.0beta1 3. Do the "This is LyX 2.3.0beta1" commit locally on 2.3.0beta1 branch without pushing Then I would upload the tar (created from my local 2.3.0beta1 branch) to be tested and built. If there are no issues, then I just push the 2.3.0beta1 branch when announcing the release. If, however, there are issues (like the Windows build cannot be made from the missing tar ball), then I do git reset --hard HEAD^ to get rid of my local "This is LyX 2.3.0beta1" commit, and we make all of the commits necessary to fix things on the 2.3.0beta1 branch, and then I make a new local "This is LyX 2.3.0beta1" commit (on the 2.3.0beta1 branch) and we go from there again. The idea behind keeping that commit local, is that we do not need to rewrite history. The advantage to this is that master would be closed for as little time as possible. Thoughts? Scott
signature.asc
Description: PGP signature
