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.

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

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?

Ruben


>
> Regards,
> Kai
>
>
> ------------------------------------------------------------------------------
> 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
>
------------------------------------------------------------------------------
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

Reply via email to