In article <[EMAIL PROTECTED]>, Gervase Markham wrote: >> That's an option for the general discussion about the nag script, but >> unless you have a time machine handy, I don't see how you're going to >> change the user agent in the 1.4 builds that are now distributed all over >> the world. :) > > Indeed; but we want to work out the long term solution as well as the > short term one.
Indeed. But if the long term problem is solved in this way, then the short term problem still needs a solution. If the solutions need to be independent, it would make sense to look at the short term problem first. >> On the wider point, I think it would be a good thing to change the UA for >> releases, but it does mean that someone (with suitable checkin permissions >> and authorisation) needs to change the revision immediately before a >> release, make a new set of builds, > > Well, you change it once you branch, so there'd be no need to make a > special set of builds. Or, you have cunning makefile logic which detects > that we are on a branch, and changes it based on the branch name. That > would be _dead_ clever. I don't see how that solves the problem - if you only change it when you branch, then the branch nightlies (and release candidates) will have the same revision as the release. >> and change it again immediately after >> (before the tree is reopened). > > That part isn't necessary; it would be changed on the branch, and stay > that way. Not following what you mean there either. Currently, after the beta is released, the trunk is changed to have the revision number for the release. Therefore, after the branch is cut, the trunk number has to change (to be 1.6a or whatever). There's no need to have separate numbering of the post-beta trunk builds and the branch builds. What's needed is to have a number on the release builds which is distinct from all the other branch/trunk builds... -- Michael
