On Thu, Oct 25, 2012 at 3:04 AM, Ruben Van Boxem <vanboxem.ru...@gmail.com> wrote: > 2012/10/24 Kai Tietz <ktiet...@googlemail.com> >> >> Hello everybody, >> >> I want to raise this discussion on public mailing-list, as mingw-w64's >> release-cycle might be also of interest to some of our users. Right >> now we do the major-release by gut feeling with a background plan >> about features new version shall include. Now I got the request to >> do major release like some other ventures - eg gcc, binutils - after a >> fixed time-line. For example if we would decide for a one-year >> release-cycle, it would Mean that we work about 6 - 8 months on new >> features, then we switch to stabelizing phase for 3 months, and then >> doing major-version branching and doing just bug-fixing on that >> branch. >> Another approach would be to do branching only if we are >> feature-complete for one version. That of course means we should >> switch from gut-feeling to more detailed feature-plan. >> >> So I would like to get your opinion. You might have complete >> different opinion about planning mingw-w64's release-cycles, so don't >> hesitate to tell us what you think about this subject. > > > Currently, trunk has several new features, some of which have matured quite > a while ago (I'm looking at you, large file support for C streams). It also > has some more WIP stuff.
If you feel that a feature is ready for stable, then communicate that to Ozkan. > In my opinion, it would have been better to have had a release for the > "finished" features, so that they can at least reach a wider audience (be > honest: not all bugs can get squished when the code is exposed to a limited > number of users in trunk). So unless some new feature breaks old features > (which is a very vague criterion, I know) release early and often. This will > increase my "workload" in building toolchains, but heck, people like regular > updates if they know things are getting cooler. Agree -- we can achieve this with communication with the stable branch maintainer. Ozkan is very good at managing those branches. We just have to tell him if we want something. > For that matter, I'm getting the psychic hunch that winpthreads integration > into the crt is waiting for v3 to be released :P > > A small pure development sidenote: I know it's possible for new features to > be developed first on a separate branch and later merged in. This is even > easier with stuff like git branches. Would a feature-based release model not > be easier to accomplish if every new feature were separated on its own > branch? That's what experimental is for. You can do your own dirty work there in whatever directory you want. ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct _______________________________________________ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
