On 9/14/2013 14:03, Kai Tietz wrote: > 2013/9/14 JonY <[email protected]>: >> On 9/14/2013 02:45, Ozkan Sezer wrote: >>> On 9/13/13, Kai Tietz wrote: >>>> Well, I consider, if we might want to define _FORCENAMELESSUNION in >>>> _mingw.h for 3.0, and remove it on our trunk. By this we reduce >>>> fallout right now, provide a version check later on for changed >>>> behavior. >>> >>> I don't know the specifics about that fallout, but is it impossible that >>> defining that would cause another fallout? >>> >> >> Alternative, we postpone dealing with it until v4, branch now and revert >> the changes in v3 so _FORCENAMELESSUNION is not needed. > > No, better to define _FORCENAMELESSUNION for v3, and remove this > define later on for trunk. I don't see an advantage to modify this > point, as by defining this macro we actual provide old behavior. > >>>> >>>> By this experience - as it must be possible to modify things on our >>>> trunk and our release cycle can take more then a year - I would >>>> encourage to change our habit of seeing trunk as release-branch. It >>>> has shown here, that this causes simply troubles on evolution. >>>> >>>> JonY, Jacek, Ozkan, your opion about this suggestion? >>>> >>>> Regards, >>>> Kai >>> >>> We will need more regular releases with safe changes merged in >>> and only unsafe stuff kept in devel branch (versus keeping new features >>> in devel branch and not merging back.) That might prevent people, to >>> some degree, from using trunk as if it is a release branch. >> >> Trunk is already the devel branch, /stable/* is for stable users. what >> we could do is make a new "/testing" that constantly have safe and >> proven changes merged from /trunk, kind of like debian-testing, where >> trunk is Sid unstable. > > I disagree. Right now we encourage our user to use trunk. So trunk > is that what I would call *mostly* stable. IMHO we need to make the > point clear to our users that in future trunk might be in-stable. And > full features are getting available with release, not before. If you > use trunk before it is release, then you are on your own to find a way > to detect if some feature is present, or not. > This approach is a paradigm-change for us. So I would like to discuss > that in front.
No, trunk is by definition always unstable and in-flux, it is where all devel work should point to, this is to prevent incompatible branches of branches springing up. Trunk should always be the canonical development reference point. Let's just call the new area /testing, with semi regular backports from trunk. Users feeling adventurous can always try trunk, if they want some stability, use /testing. If they want super stable code, use /stable. If users want to be able to detect features, I don't see why we can't add more defines to _mingw_mac.h eg __MINGW_FEATURE_HAVE_C99_SCANF, __MINGW_FEATURE_REQUIRE__FORCENAMELESSUNION etc.
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ 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/22/13. http://pubads.g.doubleclick.net/gampad/clk?id=64545871&iu=/4140/ostg.clktrk
_______________________________________________ Mingw-w64-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
