On Wed, 2010-03-17 at 20:39 +0100, Christian Stimming wrote: > Am Mittwoch, 17. März 2010 schrieb Geert Janssens: > > I have another issue related to this. I didn't pay attention to the windows > > build status, and committed a small patch this morning. Nothing fancy, just > > some small documentation fixes in the windows installer. But if changes > > have to be made to fix the 2.3.11 build on Windows, this small > > documentation fix will likely be included. > > > > I don't want to complicate the current release effort, so if you think it > > better, I'll revert my patch until the 2.3.11 build is out the door. > > Thanks for thinking about this, but it isn't necessary. The algorithm for > creating a 2.3.11 build are as follows (see packaging/win32/build_tags.sh): > > #1 Check for tags which appeared in SVN but are not in the local cache file > named "tags" > #2 Update the "tags" file with the current SVN list of tags > #3 For each of those new tags, run a separate build: > * Checkout the (current!) tag into a new checkout and separate build dir > * Build it > * Copy the log and (if succeeded) the installer to the webserver > > In step #2, the local list of tags is always updated to the current list in > SVN. This means even a failed build will not built again *unless* it has been > removed from SVN for one night (hence it disappears from the updated file) > and > added the next day (so it's new again the night after). > > Concerning your commit on trunk: Trunk doesn't influence the tag checkout, so > it's not a problem. > > Today, I'm going to log into the win32 build server later tonight and > retrigger the build myself, so we don't have to do the tag removal this time.
True. However, if a fix is needed and checked in, in order to retag, it's hard to tag the new svn head but exclude the unnecessary change. Around release time, it really is useful to have a separate branch to handle the release. In the case of an unstable build, the release engineer can merge all of trunk to the unstable release branch and tag from it. Changes can continue to go into trunk. Changes needed to create the unstable release can go on the unstable release branch and be merged back to trunk. Phil _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
