Hi Scott, I don't mean to rattle anyone's confidence but I am not a cvs expert either. What I am suggesting is a way to manage the release cycle and continue on with core feature development at the same time.
I think I understand what you are saying. Lay down a tag and if we need to go back to a point in time then we can branch at that tag, make any code fixes and re-release from that point. What I am thinking of is really quite similar, except I say that there will be code changes so when we tag, also branch. I think this is reasonable because usually releases go through an RC1/RC2 cycle (from memory I think we used this last time, please correct me if I am wrong) which are usually prompted by bug releases. The RC1/ RC2 would of course be tagged on the release branch and all bug fixes would be applied there. Probably at the time we tag this we would merge the bug fixes back into the trunk. I realize that developers will then have to be aware of which code base is the development trunk (or head) and which is the branch. It will mean two separate cvs trees locally (if you have bugs to fix, 1 if you do not) but these can be named using the options tab in tortoise so they should be fairly easy to manage. It will also make the task of fixing a bug versus refactoring a section of code explicit and should keep the risk down for letting any additional bugs creep into the release code base from large coding changes. All I am saying (and please remember this is just my opinion) is that as soon as we put up that RC1 then that is beginning our release cycle. The code base that generated that zip file should be used during the entire release cycle to make it stable as possible before we sign off on an official release. I realize that nant is still in beta but I think we can still adopt a process that is going to help us once we go beyond that. Cheers, Clayton > -----Original Message----- > From: Scott Hernandez [mailto:[EMAIL PROTECTED] > Sent: November 12, 2003 11:56 PM > To: [EMAIL PROTECTED] > Subject: Re: [nant-dev] NAnt Tag and Branch policies > > If bugs are fixed in the release branches (esp. during the beta cycles) > they > need to be merged into the head. > > What I was really getting at, with the first part of the email, is that we > should not have to do this during the beta cycle. We should only branch if > we have changes to make for an update of an old release. > > I'm trying to make an argument against using branches in the way that we > have in the past, and that it seems we are doing now. I'm arguing against > using branches at all if we can manage it. > > I'm not a cvs expert, but it seems like we are not doing this correctly if > we create a branch before we make a release. We should be rtag'n and not > branch'n. > > ----- Original Message ----- > From: "Clayton Harbour" <[EMAIL PROTECTED]> > To: "Scott Hernandez" <[EMAIL PROTECTED]>; > <[EMAIL PROTECTED]> > Sent: Wednesday, November 12, 2003 7:43 PM > Subject: RE: [nant-dev] NAnt Tag and Branch policies > > > > Scott, > > > > > The reason to keep branches to a min is that changes from one branch > > to > > > not > > > affect another. So if we fix something in 0.8.3 branch, we also need > > to > > > fix > > > all subsequent branches. Branches also require special changes to the > > way > > > we > > > as developers work. > > > > Sorry Scott, I am a little confused. Are we merging the changes in the > > release branches back into the head? Using something like the syntax: > > cvs update -j [main_trunk] -j [release_branch] > > (stolen shamelessly from > > http://www.netbeans.org/community/sources/branches.html) > > > > In theory I think that it is a lot like generating patch files and just > > applying it to the other branch. There is even a process identified on > > the netbeans site (link above) that we might use as a template. > > > > ------------------------------------------------------- > This SF.Net email sponsored by: ApacheCon 2003, > 16-19 November in Las Vegas. Learn firsthand the latest > developments in Apache, PHP, Perl, XML, Java, MySQL, > WebDAV, and more! http://www.apachecon.com/ > _______________________________________________ > nant-developers mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/nant-developers ------------------------------------------------------- This SF.Net email sponsored by: ApacheCon 2003, 16-19 November in Las Vegas. Learn firsthand the latest developments in Apache, PHP, Perl, XML, Java, MySQL, WebDAV, and more! http://www.apachecon.com/ _______________________________________________ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
