I'll look into it. I'll do a code format for the project too before branching. It'd be nice to get a clean start on code formatting, and now's the time to do it with no active branches.
-Mike On Tue, 2005-07-12 at 18:44 +0100, sebb wrote: > I don't think so, but I'm not 100% sure. > > S. > On 7/12/05, Michael Stover <[EMAIL PROTECTED]> wrote: > > Has there been any work done in the 2.0 branch since our last merge? > > > > -Mike > > > > On Tue, 2005-07-12 at 18:29 +0100, sebb wrote: > > > OK. > > > > > > So let's go with a 2.1 branch, in which we fix bugs only to create > > > 2.1.1, 2.1.2 (hopefully not many more). > > > > > > Meanwhile changes to HEAD accumulate for 2.2 etc. > > > > > > I think (hope!) 2.0 was a special case. > > > > > > S. > > > On 7/12/05, Michael Stover <[EMAIL PROTECTED]> wrote: > > > > 2.1.0 and 2.1.1 can be done in a couple different ways. In the 2.0 > > > > branch, 2.0.0 was the first release and it was simply a tag on the > > > > branch (not a new branch). 2.0.1 was further down the line of the 2.0 > > > > branch, and a new tag was created for it. Ditto 2.0.2 and 2.0.3. All > > > > those were just snapshot points along the 2.0 line. In fact, RC1 and > > > > RC2 would be exactly the same - just snapshots. > > > > > > > > I'd prefer to continue doing that same thing for 2.1. The other option > > > > is to make new branches for every point release, which I feel > > > > complicates the issue and doesn't get you a whole lot. I don't think > > > > it's good to have too many branches and our volunteer committers unsure > > > > of where their commits should go. > > > > > > > > However, with 2.0, we got into a lot of feature enhancements within that > > > > branch, and, IMO, that contributed to delaying the release of 2.1, > > > > because we were simply doing a lot of new stuff in 2.0, whereas, IMO, > > > > these branches should strictly be bug fixing, and new enhancements done > > > > in HEAD where they will be released in 2.2. The difference is, ideally, > > > > we push for 2.2 in 3-4 months, not 12. > > > > > > > > -Mike > > > > > > > > On Tue, 2005-07-12 at 18:06 +0100, sebb wrote: > > > > > OK, I see - I think. > > > > > > > > > > So when we want to produce 2.1.1 we create another branch (and tag)? > > > > > > > > > > BTW, should this one be called 2.1.0 ? > > > > > > > > > > S. > > > > > On 7/12/05, Michael Stover <[EMAIL PROTECTED]> wrote: > > > > > > The point of the branch is to assist with a feature freeze for the > > > > > > release, without interfering with anyone's desire to continue on > > > > > > with > > > > > > new work. Right now, if we are ready for a release candidate, we > > > > > > are > > > > > > ready for a feature freeze for 2.1, leaving HEAD free for new work. > > > > > > 2.1 > > > > > > would just be for bug fixes, essentially. > > > > > > > > > > > > I'm going to go ahead and make the branch unless I hear back not to. > > > > > > I'll wait though, give y'all time to respond to this. > > > > > > > > > > > > -Mike > > > > > > > > > > > > On Tue, 2005-07-12 at 17:21 +0100, sebb wrote: > > > > > > > There'll always be some more bits to tweak, but I think the > > > > > > > codebase > > > > > > > is now OK for a release candidate. > > > > > > > > > > > > > > Just wondering if creating the branch should not wait until the > > > > > > > RC has > > > > > > > been tested? > > > > > > > > > > > > > > I.e. create a 2.1RC1 tag, build and release RC1. > > > > > > > > > > > > > > If that's all OK, then create the 2.1 tag and branch. > > > > > > > > > > > > > > Or is that unnecessary? > > > > > > > > > > > > > > S. > > > > > > > On 7/12/05, Michael Stover <[EMAIL PROTECTED]> wrote: > > > > > > > > Hey Sebb, > > > > > > > > Pete's ready for 2.1 to branch - are you? > > > > > > > > > > > > > > > > -Mike > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > 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] > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > 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] > > > > > > --------------------------------------------------------------------- > 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]
