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

Offline troels

  • Multiple posting newcomer
  • *
  • Posts: 71
Re: Release Early, Release Often
« Reply #15 on: November 27, 2006, 02:47:26 pm »
If code-completion is what is holding you back, just disable it by default, so what if one feature is not there yet

Same with wxSmith, it should be ok to make it disabled by default if it's 'not there' yet. I use wxWidgets myself, but the 'majority' of potential users won't know what it is.

Regards

Offline dmoore

  • Developer
  • Lives here!
  • *****
  • Posts: 1576
Re: Release Early, Release Often
« Reply #16 on: November 27, 2006, 05:58:15 pm »
I'm not one of the developers, but I've at least taken a good look at the code and have been working on plugins, which has given me some insight into why there is still no RC3

IMO, it's not just a matter of turning off some of the difficult plugins and patching them up later. Almost all of Code::Blocks is built around plugins and an sdk to develop those plugins. Plugins are used not only for optional features like editor refinements and code helpers, but also for core tasks such as compiling and debugging (some people would also consider code completion a core feature of a graphical IDE). While these plugins are still in development, the C::B sdk will need little tweaks here and there (how can you know if your SDK is flexible/stable enough if it hasn't been tested on fully fleshed out plugins?). It won't possible make those tweaks without breaking any current build marked as a RC, making it no more useful than any of the nightly builds. I could only imagine the user backlash.

The fact is the C::B devs made the difficult decision to go back to the drawing board rather than release a product with so many limitations. As the download page says, Code::Blocks has expanded into unexpected directions as a result. From my perspective, not one of the expansions that the dev team is working on is "frivolous", but rather is geared at making Code::Blocks more stable and flexible. This has obviously taken a lot longer than any one of them anticipated.

Of course, the Release candidate tags are misleading at best. The current C::B is a totally different beast from the C::B of 12 months ago. I'd go far to say that what the devs are working on is C::B 2.0 and that they have simply abandoned 1.0 (although maybe it would be bad marketing to badge it with a 2.0 if 1.0 failed to materialize). As far as marketing goes, I think the mainpage could be changed to reflect the active development that is going on, but that will take someone away from coding...

Anyway, to all those who are impatient, there's lots you can do. Study the code, report and fix bugs, work on plugins, add documentation etc.

Offline BigAngryDog

  • Multiple posting newcomer
  • *
  • Posts: 75
    • BigAngryDog.com
Re: Release Early, Release Often
« Reply #17 on: November 27, 2006, 06:47:53 pm »
At the end of the day, the issue is whether it is a good idea to have a download of C::B on the website front page which is over a year old. Instead, there's a long paragraph explaining why C::B has been updated in over a year and that the nightlies are much better and people should really go figure how to get them. But if that's the case--then would not a more recent version of C::B on the front page be better?

CodeBlocks versioning has been discussed before, and as I recall, the developers decided to stick with RCX.x. To my mind, it is a mistake because RC1/2 (and 3?) are not release candidates at all--they are alphas. It also seems that the notion of "release candidate" is preventing a more public release process.

It is up to the developers what they do with CodeBlocks, and they don't have to listen to anyone. If I had the time, I would want to get involved, and put my money where my mouth is. But I strictly don't have the time. I'm gonna leave it there cos I'm sure the devs are fed up with us users banging on about RC3.

Can't help thinking though...

How many people would be stuck with IE today if the Mozilla website had a download of version 0.2 of Firefox and long paragraph explaining why there hadn't been an update in x years and that people should join the forum and download a nightly because there so much better than the official release?
BigAngryDog.com

Offline dmoore

  • Developer
  • Lives here!
  • *****
  • Posts: 1576
Re: Release Early, Release Often
« Reply #18 on: November 27, 2006, 07:17:15 pm »
At the end of the day, the issue is whether it is a good idea to have a download of C::B on the website front page which is over a year old. Instead, there's a long paragraph explaining why C::B has been updated in over a year and that the nightlies are much better and people should really go figure how to get them. But if that's the case--then would not a more recent version of C::B on the front page be better?
...
How many people would be stuck with IE today if the Mozilla website had a download of version 0.2 of Firefox and long paragraph explaining why there hadn't been an update in x years and that people should join the forum and download a nightly because there so much better than the official release?

yeah, I agree that this is largely a marketing issue

CodeBlocks versioning has been discussed before, and as I recall, the developers decided to stick with RCX.x. To my mind, it is a mistake because RC1/2 (and 3?) are not release candidates at all--they are alphas. It also seems that the notion of "release candidate" is preventing a more public release process.

yes, it is pretty obvious that if they were labelled alphas (even betas) there would be far more frequent updates. branching the code, as others have proposed, would be a far worse mistake though.

Offline Commodore64

  • Multiple posting newcomer
  • *
  • Posts: 35
Re: Release Early, Release Often
« Reply #19 on: November 28, 2006, 11:10:05 am »
Just a humble suggestion: another open source project used to publish official releases called "Technology Previews" (TP for short): TP1, TP2, etc. People were encouraged to download TP's, even if they were not "stable" releases. I think users felt quite confortable with installing and using a TP... I know, it's only a psychological issue!

Thus you could take a nightly build, deem it a TP (or... an "Interim Release", or whatever), and put it in the download page nicely packed with an installer, optionally with MinGW, etc.

Just my 2 cents (of Euro, of course :P)