I'm a bit confused by mingw-w64 releases. I mean especially the stable 1.0 builds now hosted on Windows natively (i.e. the mingw platform) targetting both win32 and win64. At the moment the latest 1.0 mingw-hosted packages are mingw-w32-1.0-bin_i686-mingw_20101129.zip and mingw-w64-1.0-bin_i686-mingw_20110207.zip respectively.
gcc from the first package advertises itself as 4.5.2 (prerelease) while the gcc from the second package advertises itself as gcc 4.5.3 (prerelease).
Why the packages are not released in sync (both in time and with the same version of included tools)?
Why the gcc versions packaged are not the latest "official" gcc releases? I know there is no 4.5.3 released by http://gcc.gnu.org team yet but there was no 1.0 mingw-w64 release using the final 4.5.2 in meantime, or was it?
So I'm wondering what's the release policies.
The buildbot pulls from gcc svn branch. As of November 29 2010, GCC 4.5.2 has yet to be released, so after that date, svn branch is 4.5.3.
What you are seeing are the daily automated builds, not official releases, there are no release controls nor are humans involved. See the personal builds section for toolchains released by some of the users/developers.
Thanks for the reply, but it somehow did not make it less mysterious to me.
http://mingw-w64.sourceforge.net/ says: "Project Status: Version 1.0 has been released and is considered stable."
The only packages containing the "1.0" version identification are some of those built automatically. If they all are built automatically what's the key why some of them do deserve "1.0" and the other do not?
There are personal builds of several developers but I could not find any marked as "1.0". Also there is not much clue how to choose my favorite developer…
So how all these facts play together?
The 1.0 refers to the mingw-w64 svn branch, its quite old in comparison to trunk, likely those recent release without the 1.0 mark uses trunk code.
As for personal builds, you will have to ask the uploader for the details on what is in included in their offerings.
I echo the poster's confusion regarding this. When you say a release is "stable", that should mean that only bug fixes are incorporated into new builds bearing that release tag. If that is the case, then it needs to be made obvious what has changed from one stable build to the next. I personally don't want to download a new 300-megabyte build of MinGW64 to fix one problem, only to find out that it creates five new ones.
I would suggest moving these automated builds into a new directory once they become official releases and keeping a change log of the builds.
Log in to post a comment.