Author Topic: Release Early, Release Often  (Read 20074 times)

joat

  • Guest
Release Early, Release Often
« on: November 22, 2006, 11:52:30 pm »
I think that the fact that RC2 is over a year old is really hurting the project. When I first found the Codeblocks website and saw how old RC2 was I figured the project was pretty dead (this was before the site was changed to point people to the nightly builds). To verify if the project was dead I figured I'd check out the forums to see if there was any info about the status of the project. I found that the forums were quite active and that there were nightly builds being posted. Nevertheless, I really didn't want to be bothered with figuring out which nightly build  was the most stable to use or bothering to check the forums every day and download and install a newer build. I then went back to using Dev-C++ since I really hadn't had any trouble with it. Later on my curiosity finally overcame me and I went back to the site and downloaded a nightly build to try out. Once I ran Codeblocks I was hooked. The problem that I see is - what about all the people who don't want to be bothered with updating every day so they don't even try Codeblocks out?

I am very enthusiastic about Codeblocks and I believe the developers are doing a fantastic job. However, I would suggest that you guys take a look at http://www.firstmonday.org/issues/issue3_3/raymond/ - especially the section entitled "Release Early, Release Often." It is a very interesting article with some good points about open source development. I know you guys are sick of having people bug you about RC3, so here's my point - please just pick a nightly build, branch it, and then eliminate the bugs for a bit and call it RC3. I know you have a feature list for RC3 and that everything isn't quite ready, but just make the current RC3 feature list for RC4. RC feature lists don't have to be set in stone and by waiting so long I think the project is really hurt in terms of gaining users. Another possible solution would be to add an auto update feature to Codeblocks (yes I know this is in the feature list for RC3) and allow it to update by releases or nightly builds. This would satisfy people that just want to run a stable version and people that enjoy tinkering with the cutting edge. I think that having Codeblocks update itself would also take care of people not wanting to go to the forums to find out if there's a new build and then download and install it every day. Having an updated stable release would really help the project. All I ask is that you at least take my experiences with Codeblocks and suggestions into consideration.

Offline troels

  • Multiple posting newcomer
  • *
  • Posts: 71
Re: Release Early, Release Often
« Reply #1 on: November 23, 2006, 10:47:48 am »
I know you guys are sick of having people bug you about RC3...
Even so, I'll chime in and second what joat says above, RC3 is overdue. If code-completion is what is holding you back, just disable it by default, so what if one feature is not there yet, even a popular one. CB is well-constructed, this is what counts. "Feature-completeness" can be left for version 1.1.
Regards
« Last Edit: November 23, 2006, 10:49:21 am by troels »

Offline bertg

  • Single posting newcomer
  • *
  • Posts: 3
Thirded
« Reply #2 on: November 23, 2006, 01:31:51 pm »
I'm still using RC2 because it somewhat works the way I want.
Trying to use NB's for my development work has been too much of a mental hurdle for me.
I know the developers have every right to do with this project whatever they want.
If they want to play teasing games by dangling an RC3 in front of the user community and then going off on an endless refactoring fest - that's their call.
But I find this unfortunate because I would not like to see this great project dying a slow death.

Offline BigAngryDog

  • Multiple posting newcomer
  • *
  • Posts: 75
    • BigAngryDog.com
Re: Release Early, Release Often
« Reply #3 on: November 23, 2006, 02:10:20 pm »
My opinion and suggestion as a grateful user...


>I think that the fact that RC2 is over a year old is really hurting the project.

I agree.


>If code-completion is what is holding you back, just disable it by default,

I agree.


By the time C::B eventually reaches release status, the world could have moved on.

90% of visitors will see the web site home page and never bother with a nightly.

If you have to pick a recent nightly which is stable, give it an installer and call RC3--then do that.

BigAngryDog.com

Offline BCCISProf

  • Multiple posting newcomer
  • *
  • Posts: 60
    • Professor Langsam's Home Page
Re: Release Early, Release Often
« Reply #4 on: November 23, 2006, 02:44:34 pm »
In the meantime, there is a Windows XP installer for the whole package as well as a manual here:

http://www.sci.brooklyn.cuny.edu/~goetz/codeblocks/

We try to keep the installer reasonably updated with a stable nightly build and will continue to do so.


Offline batwings

  • Single posting newcomer
  • *
  • Posts: 3
Re: Release Early, Release Often
« Reply #5 on: November 23, 2006, 02:58:11 pm »
MISSION:RC3-IMPOSSIBLE

What is preventing us from challenge it?
No doubt, any nightly build now is reaching the goals of RC3 milestone.

It is the time for team to spend a little bit time to make a RC3 release.

Offline DC@DR

  • Multiple posting newcomer
  • *
  • Posts: 23
Re: Release Early, Release Often
« Reply #6 on: November 23, 2006, 07:19:28 pm »
Yes, I strongly agree that we should "release more, release often". It's true that many users won't bother to see what's going on with the nightly builds, and when they find out that the RC2 stays there for approx. 1 year, they will surely assume that the project has gone to an end/death, then they just move on without thinking about a return visit. That's sad, devs, since we need more users, we need to spread the word, that's the idea of open source community to fight for right to exist in the contemporary commercial universe :)
« Last Edit: November 23, 2006, 07:21:47 pm by DC@DR »

Offline kidmosey

  • Multiple posting newcomer
  • *
  • Posts: 95
    • MUSITU International
Re: Release Early, Release Often
« Reply #7 on: November 24, 2006, 07:50:56 am »
90% of visitors will see the web site home page and never bother with a nightly.

where do you get this statistic?


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.
3 years until google knows more than god.

Offline bertg

  • Single posting newcomer
  • *
  • Posts: 3
Re: Release Early, Release Often
« Reply #8 on: November 24, 2006, 11:47:22 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.

There's more to it than just a postfix on a filename. When you use a nightly build, you volunteer to test out bleeding edge code that has been introduced into the project <24hrs ago. And that is a good thing. After all, many volunteer testers make a free software project work.

But there are also people, like me, who don't have the guts or the time to use untested releases. For these people a release branch where the only expected changes are bugfixes would be great. My bet is that the number of people who are genuinely interested in CodeBlocks - but too squeamish to get involved in testing - is an order of magnitude greater than the number of people actively testing.

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.
« Last Edit: November 24, 2006, 04:24:47 pm by bertg »

Offline BrianSidebotham

  • Multiple posting newcomer
  • *
  • Posts: 45
Re: Release Early, Release Often
« Reply #9 on: November 24, 2006, 07:01:31 pm »
I don't visit the forums for the nightly builds, in fact I rarely visit the forums! :( I start the day with a cup of tea and "svn update" to see what's changed. I can normally tell by whats updated whether it's worth a re-compile or not.

I actually quite like the system, and the nightly builds are not what I would class as unstable at all. For a few people mainly working on the project, there is on average an update per day and you can't ask for more than that.

As for the comments about turning code completion off, I answer with WHAT!? That imo is pretty much c::b's most powerful feature. It's pretty much the single reason I use it. c::b isn't geared towards embedded C development, but the code completion is much better than in any other open source ide. I really get on with it. If you took that out, I'd go back to programmers notepad.

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!

Offline BigAngryDog

  • Multiple posting newcomer
  • *
  • Posts: 75
    • BigAngryDog.com
Re: Release Early, Release Often
« Reply #10 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.
BigAngryDog.com

Offline kidmosey

  • Multiple posting newcomer
  • *
  • Posts: 95
    • MUSITU International
Re: Release Early, Release Often
« Reply #11 on: November 25, 2006, 02:06:32 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.

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)?

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.

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".
3 years until google knows more than god.

joat

  • Guest
Re: Release Early, Release Often
« Reply #12 on: November 26, 2006, 03:39:43 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.

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 -

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.

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.

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.

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.

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.

Offline kidmosey

  • Multiple posting newcomer
  • *
  • Posts: 95
    • MUSITU International
Re: Release Early, Release Often
« Reply #13 on: November 26, 2006, 03:10:41 pm »
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.

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).

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.
3 years until google knows more than god.

Offline Game_Ender

  • Lives here!
  • ****
  • Posts: 551
Re: Release Early, Release Often
« Reply #14 on: November 27, 2006, 01:55:55 am »
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".