Charley Bay wrote: > Honest question, this isn't a proposal, but don't we have *TWO* issues > being considered? > > (1)- "Levels-of-stability" (for the next release) > (2)- "Evolving-APIs/Features" (for future releases) > > I don't want to "explode" the issue, but that seems to imply (to me) > something like: > > *- NextMajorRelease (API changes allowed) > *- master > *- beta > *- stable
While I am of the opinion we need to find better ways to work on NextMajorRelease features before embarking on such a mission, I don't think it will work to have a branch where such changes accumulate. For one, it will be hard to keep it up-to-date with feature development in NextMinorRelease. Another issue is that without wide exposure quality will slowly degrades as more untested features keep creeping in. This makes it a big PITA when time comes for us to do something useful with this branch. Releases and release pressure are needed to keep the code in check. It's basic code psychology :-) > *- NextMinorRelease (source compatible) > *- master > *- beta > *- stable > *- NextDotRelease (binary compatible) > *- master > *- beta > *- stable Cheers, João _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
