On 10/25/2012 15:04, Ruben Van Boxem 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 any branching is going to happen, please hold on, I'm still doing some final testing on the vswprintf fix for libstdc++ to_string. Well, it shouldn't break anything since it wasn't working before anyway. > 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. > > For that matter, I'm getting the psychic hunch that winpthreads integration > into the crt is waiting for v3 to be released :P > Yes please, make it happen :) > 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? Well, the problem with that is that branches tend to diverge if not maintained. This can be a problem if multiple branches do some incompatible changes and try to merge to trunk later. I still prefer trunk to be the in-flux devel tree, we already have branches for the stable stuff, managed finely by Ozkan thus far.
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ 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
