I almost didn't read this thread, based on the subject line, but I'm rather glad that I did, given how far the subject has strayed...
There is still a need for a freeze after tagging. While it's not quite as essential as with our previous release process, it's still important. Here's why. The tag happens before the release build is made, and so obviously before that build is tested. It is quite common that some tweaks need to be made after the tag is initially applied, and before the release is made available. Examples are updating an incorrect version number, either in the build file or in the docs, fixing something that is trivially broken, whether it be functionality or a test, etc. Now, if someone had checked in a big change right after the release was tagged, but before the release was done, that somewhat limits the options of the RM for getting the release right. If the RM needs to fix a version number in the build file, but a whole new feature has been added that also involved changes to the build file, the choices become (a) proceed with a release that has the wrong version number (bad), (b) pick up the new feature that has not even been seen in a nightly build yet (bad), or (c) abandon the release (bad). So, at least as long as folks are happy with me as the RM, please allow me the leeway of a short freeze period between tagging and releasing the build, so that I can do the job as best I can. I don't think that should be too onerous. As for 1.2.0, I'd like to ask that people not change the build files until I get it rebuilt with Struts-EL included (hopefully this evening), in case I need to make changes there. However, you can consider the tree open for other changes, to be included in 1.2.1 (i.e. please don't move the tags). -- Martin Cooper On Tue, 24 Feb 2004, Ted Husted wrote: > Yes, under the current process, there little reason to have a real "freeze". It's > more like a heads-up now. > > AFAIC, the codebase should not be considered frozen now, and people can start > applying fixes to go into 1.2.1, including the license thing. > > The only reason we're not starting a vote on the quality of 1.2.0 is because of an > ISP glitch. > > If 1.2.0 dies on the vine, then we can just roll 1.2.1 at any convenient juncture. > > -Ted. > > > On Tue, 24 Feb 2004 15:13:38 -0600, Joe Germuska wrote: > > At 6:28 PM +0000 2/24/04, [EMAIL PROTECTED] wrote: > > > >> Once a release is tagged that's it. We could retag and do 1.2.1, > >> however there will probably be other things that need to be > >> fixed. The point is to get 1.2.0 out the door and then see about > >> making whatever fixes that need to happen. > >> > > > > Well, if it's tagged, then I don't have to wait to commit the > > change; there's no need for a freeze, as you can always check out > > to the tag and use that to cut the release. No need to wait to > > apply the license patches either. (I will wait, however, until I'm > > sure other people see it the way I do.) > > > > Of course, it's possible to move CVS tags -- I assume you're just > > saying that you think that that's procedurally wrong? I'm not sure > > I agree, but I don't feel very strongly about it either. In fact, > > I'd much rather see 1.2.0 come out, with as few delays as possible. > > > > Joe > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
