I don't want branching done unless we have to. Unless there is a reason we *need* to branch, then we should not.
We should change our release plan on the wiki. http://nant.sourceforge.net/wiki/index.php/ReleaseProcess Please see additional comments inline. ----- Original Message ----- From: "Clayton Harbour" <[EMAIL PROTECTED]> > 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 understand what you are suggesting, I don't like that plan. From what I've read, and the stories I've heard from other projects, and people who have used, and understand, cvs much more than I do, it is best not to branch unless there is a very good reason. CVS is not VSS, SVN, or any other source control system. Even though all these system work very similar in concept, there are some very serious differences in application. > > 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. Why should each developer need to maintain a seperate source branch on their local machine? If we use tags we just work from the head until we are ready for the releases. We will still have access to those specified versions of files based on that tag. If at any point we need to branch, we can from the tag. :) > 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. I understand what you are going for. I think we should keep it simple and just use tags and not branches unless we start getting serious restructuring on code during beta/rc cycles of a release. One of the point of keeping the list updated is that we don't have that happen, we won't see massive changes since devs know to hold that kind of stuff off till after the release. Yes, setting up and keeping a good process will make it easier for people to jump in and keep things going. No question about that. :) ------------------------------------------------------- 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
