On 9/16/2013 4:38 AM, JonY wrote: > On 9/16/2013 19:17, Earnie Boyd wrote: >> IMO, trunk is a stable branch that all other branches evolve from. >> You create a working branch named for the next release that all work >> is done to and is unstable up until the call for testing. After the >> call for testing only bug fixes for that release occur that are found >> within the soon to be released branch. Just before releasing that >> working branch is merged into trunk and tagged for the release. A new >> working branch is created from the merged trunk to continue >> development. If there is a bug fix for the previous release you use >> the previous working branch to make the bug fix, merge that fix back >> to trunk, tag the trunk with the bug fix version, then merge trunk >> with the new working branch. In this way, trunk becomes the master of >> the work and should always be usable regardless of the stage of >> development. The only time trunk should be a working branch is for a >> new project where there is no release. >> > What? No, you have it backwards, trunk is where all development work > will take place, unless the code in question is known to be broken > work-in-progress code. There is already a /stable branch code, we don't > need another stable branch, maybe another /stable/latest to point to the > latest stable as new releases are made.
I have been with groups that used the trunk as the stable, released and released-patched source and side branches for developing the next release and other groups that used the trunk as the current development source and various branches as the released and patched-released source; in the first case, the trunk will be development prior to the very first release. It is like little endian and big endian -- different groups have opted for different choices. But I am puzzled by the following in the last quoted para above: "trunk is where all development work will take place, unless the code in question is known to be broken work-in-progress code" -- if the trunk is where all the development work will take place then it is work-in-progress code and is likely to have bugs (because it would not have undergone release tests); in this situation, the only guarantee one can enforce is that before commits, people ensure that the trunk compiles and passes any regression tests. > > What mingw-w64 needs is a more frequent release schedule. When gcc-4.8 > was released, it required trunk version. v3 should have been released > then. Trunk was already fairly stable at the point, except everyone was > complacent and the schedule slipped. > > Still waiting for a test report from Erik before the final can be released. > > > > > ------------------------------------------------------------------------------ > LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! > 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint > 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes > Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. > http://pubads.g.doubleclick.net/gampad/clk?id=58041151&iu=/4140/ostg.clktrk > > > _______________________________________________ > Mingw-w64-public mailing list > Mingw-w64-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public ------------------------------------------------------------------------------ LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. http://pubads.g.doubleclick.net/gampad/clk?id=58041151&iu=/4140/ostg.clktrk _______________________________________________ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
