User forums > General (but related to Code::Blocks)
Release Early, Release Often
BigAngryDog:
>I don't see why people are so desperate to see a current nightly build labeled RC3. Just use a nightly build and have done!
It isn't cos I can't live without a version labelled RC3--I download nightlies pretty regularly. Rather I think those of us arguing for RC3 are doing so because we care about the success of C::B overall.
kidmosey:
--- Quote from: BigAngryDog on November 24, 2006, 08:23:22 pm --->I don't see why people are so desperate to see a current nightly build labeled RC3. Just use a nightly build and have done!
It isn't cos I can't live without a version labelled RC3--I download nightlies pretty regularly. Rather I think those of us arguing for RC3 are doing so because we care about the success of C::B overall.
--- End quote ---
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)?
--- Quote from: bertg on November 24, 2006, 11:47:22 am ---Right now, the project finds itself in a loop between the developers and a group of "hardcore" alpha testers. If a relatively stable release could be spun every 6 months or so, CodeBlocks would find its way to a much larger user community. More testers, developers and plugin writers could trickle down from this community to give the project a helping hand. It's up to the core developers to decide if that kind of exposure is desirable at this stage.
--- End quote ---
It is true that an RC3 will expand the user base and add more people to test C::B, but it will also add quite a few more people who's intention isn't for testing but for development, and any and all bugs that are discovered by those people will be attributed to bad software (and won't be reported). If you've ever been in retail, you know that people are 10 times more likely to spread bad impressions to their peers than good impressions.
I do think including "relatively stable" development snapshots would be a good idea, but it will still be seen as "not RC3".
joat:
--- Quote from: kidmosey on November 24, 2006, 07:50:56 am ---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.
--- End quote ---
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).
--- Quote from: kidmosey on November 25, 2006, 02:06:32 pm ---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)?
--- End quote ---
This is why i said -
--- Quote from: joat on November 22, 2006, 11:52:30 pm ---please just pick a nightly build, branch it, and then eliminate the bugs for a bit and call it RC3.
--- End quote ---
Also, to quote from the download page of Codeblocks -
--- Quote ---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.
--- End quote ---
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/ -
--- Quote ---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.
--- End quote ---
--- Quote ---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.
--- End quote ---
--- Quote ---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.
--- End quote ---
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.
kidmosey:
--- Quote from: joat on November 26, 2006, 03:39:43 am ---Also, to quote from the download page of Codeblocks -
--- Quote ---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.
--- End quote ---
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).
--- End quote ---
Good point... The only thing RC2 has going for it is it has mingw included in one of the packages.
As for your versioning suggestion, I think they've shot that down before for one reason or another.
This is all best summed up by http://forums.codeblocks.org/index.php?topic=1406.0. I kind of like Mandrav's suggestion to do away with versions entirely.
Game_Ender:
I think I see the problem (someone correct me if I am wrong): We have a lot of great coders on this project, and they have made a good IDE, but they seem to be addicted to new features and always finishing just "one" more thing. Thats not to say they don't not fix bugs, they get fixed them when ever they come up.
I agree with Joat's strategy and if developers don't like attending to a bug fix only branch, there are plenty of members of the CB community which will be happy to provide the needed patches until it ready to be relased into the wild.
Honestly I can't see why you wouldn't want follow Joat's strategy. "We are not a company/we don't make money" != "We don't have to be organized".
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version