When I went to download, I saw on the page where it said many of the nightlies are as much or more stable than RC2, so I downloaded a nightly. Maybe this puts me among the "10% of visitors" that doesn't care about the postfix on an application name, but about the application functionality.
Again, it's not about a postfix on the name of the application or functionality, but about having a choice. If you want the latest features, then you should have the option to run a nightly build. On the other hand, if you want stability and a minimal number of bugs, you should have the option of using a stable release (which RC2 is clearly not according to the download page).
The success of the project is more dependent on the quality of the stable release than the speed at which it is released. Mislabeling it as a release candidate when there are potentially fatal flaws could be quite damaging to the success of C::B. How many people would react like whats-his-name who lost an entire file due to an undiscovered bug (in a development snapshot, iirc)?
This is why i said -
please just pick a nightly build, branch it, and then eliminate the bugs for a bit and call it RC3.
Also, to quote from the download page of Codeblocks -
As a matter of fact, any recent snapshot is much more stable than our last "stable" release (so called 1.0rc2). In terms of features any snapshot is leaps ahead 1.0rc2.
This is why we need a new stable release. If people decide not to use the bleeding edge nightlies and instead go with RC2, they are actually worse off in terms of stability (not to mention features).
Three important quotes from the article I previously suggested one read at
http://www.firstmonday.org/issues/issue3_3/raymond/ -
Early and frequent releases are a critical part of the Linux development model. Most developers (including me) used to believe this was bad policy for larger than trivial projects, because early versions are almost by definition buggy versions and you don't want to wear out the patience of your users.
This belief reinforced the general commitment to a cathedral-building style of development. If the overriding objective was for users to see as few bugs as possible, why then you'd only release one every six months (or less often), and work like a dog on debugging between releases. The Emacs C core was developed this way. The Lisp library, in effect, was not - because there were active Lisp archives outside the FSF's control, where you could go to find new and development code versions independently of Emacs's release cycle.
The most important of these, the Ohio State elisp archive, anticipated the spirit and many of the features of today's big Linux archives. But few of us really thought very hard about what we were doing, or about what the very existence of that archive suggested about problems in FSF's cathedral-building development model. I made one serious attempt around 1992 to get a lot of the Ohio code formally merged into the official Emacs Lisp library. I ran into political trouble and was largely unsuccessful.
But by a year later, as Linux became widely visible, it was clear that something different and much healthier was going on there. Linus' open development policy was the very opposite of cathedral-building. The sunsite and tsx-11 archives were burgeoning, multiple distributions were being floated. And all of this was driven by an unheard-of frequency of core system releases.
Here, I think, is the core difference underlying the cathedral-builder and bazaar styles. In the cathedral-builder view of programming, bugs and development problems are tricky, insidious, deep phenomena. It takes months of scrutiny by a dedicated few to develop confidence that you've winkled them all out. Thus the long release intervals, and the inevitable disappointment when long-awaited releases are not perfect.
In the bazaar view, on the other hand, you assume that bugs are generally shallow phenomena - or, at least, that they turn shallow pretty quick when exposed to a thousand eager co-developers pounding on every single new release. Accordingly you release often in order to get more corrections, and as a beneficial side effect you have less to lose if an occasional botch gets out the door.
In case there are serious bugs, Linux kernel version are numbered in such a way that potential users can make a choice either to run the last version designated "stable" or to ride the cutting edge and risk bugs in order to get new features. This tactic is not yet formally imitated by most Linux hackers, but perhaps it should be; the fact that either choice is available makes both more attractive.
I simply think that releases should be made more often and progress made in increments instead of one giant change. No one wants to wait a long time for all the features to be implemented.
Here's my suggestion as to how the development process should work using CB 1.2 as an example.
General Ideas: As features are added make minor releases (1.1.1 1.1.2 1.1.3 etc). There should be two versions of the program offered - a stable release and a release candidate. (Anyone wanting the very latest could just grab the svn source and build it himself).
Development Process:
1) Make a list of features for the major release. (make a CB-1.2 Feature list page on the wiki)
2) Implement a couple of the features from the feature list into the release candidate and call it CB-1.1.1-rc1
3) As bugs pop up they should be fixed and the release candidate updated. (CB-1.1.1-rc2 CB-1.1.1-rc3 etc)
4) Once this release candidate seems stable (no more bugs are popping up) it should be released. (CB-1.1.1)
5) Repeat 4-6 until all features for the major release are implemented and tested.
6) Release the major release. (CB-1.2.0)
7) Start the process again for the next major release
Using this process would hopefully satisfy everyone. There would be stable releases for people that require a stable version and there would be release candidates for those who wish to test the latest features. In addition, this would benefit those who wish to use the stable version since they would get new features more often without losing stability. Anyone who comes to the site now without looking at all the changelogs for the nightly builds since RC2 has absolutely no idea of the incredible amount of work the developers are putting into CB. Since releases would happen more often the project would seem much more active to anyone who comes to the site. This would likely help the project to grow rapidly (something I would very much like to see happen). I ask the developers to please take these ideas into consideration as I believe they will greatly benefit CB.