David M. Cooke wrote: > That's one reason that I'm careful (or least try to be) in my change messages > to mention the ticket number for the bug fixed in the first line, so that > Trac will show it in the source browser, and to mention the revision number > of the fix in the ticket itself. The comment for stuff merged from one branch > to the other mentions which revisions are being merged from the original > branch (again, on the first line so Trac will see it). If applicable, add the > merge to the ticket also. > > Merging a bug fix between trunks as soon as possible is a good idea too! > > Then it's a relatively simple matter to browse through Trac and see what's > been merged, and what commits fix which.
The problem is that it's still a lot of work keeping two branches in sync with each other over long periods of time. Until 1.0 final goes out, everything getting checked into the 1.0 branch should also be on the trunk. Once 1.0 final is out and the 1.0.x maintenance series begins, that's the time to branch since the branch is then intended to be different from the trunk. My experience with long-lived branches is quite bad. They've caused me a lot of problems at work. -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
