The 21 July 2009 build (5696) is out.

[Alexis]

I've never used SVN access to the sources and I've never build a binary version myself. Just use the nightly builds, that are advertised in this forum.

Yes, getting the archive makes SVN unnecessary.

Maybe they should call them differently and just release them as normal versions, because that's basically what they are.

No, they are not. Regular "official" releases are usually preceded by alpha, beta and release candidates. There is no evolution anymore, only bug fixing, and software is thoroughly, extensively tested.

With nightly builds, you have bug fixing, but also new features. So you can never be sure you will not face regressions. With official releases, you can expect a quite high confidence level in the soft.

[Jenna]

I noticed this from a couple of nightly builds back and filed a bug report which can now be closed:

http://developer.berlios.de/bugs/?func=detailbug&bug_id=16032&group_id=5358

Done, thank you for reminding !

[kad77]

Maybe they should call them differently and just release them as normal versions, because that's basically what they are.

No, they are not. Regular "official" releases are usually preceded by alpha, beta and release candidates. There is no evolution anymore, only bug fixing, and software is thoroughly, extensively tested.

With nightly builds, you have bug fixing, but also new features. So you can never be sure you will not face regressions. With official releases, you can expect a quite high confidence level in the soft.

You stated my point better than I. Many people don't want to roll the dice with SVN builds (precompiled or not). I assume sometimes CB undergoes minor surgery for new features, making nightlies unstable for a while.

I read the wikipedia article, and it seems 'endless beta' is in the culture here @ CB, but for the sake of users, or to grow potential users consider a 9.08 release that doesn't have blockers or regressions. Thanks for reading. 

[geiermeier]

No, they are not. Regular "official" releases are usually preceded by alpha, beta and release candidates. There is no evolution anymore, only bug fixing, and software is thoroughly, extensively tested.

The updates for e.g. TortoiseSVN (which is probably very widely used) are bugfix+feature updates. And everyone gets a new version number and is official. I'd say they're about equal to CB's nightlies even with a similar frequency.

[kad77]

No, they are not. Regular "official" releases are usually preceded by alpha, beta and release candidates. There is no evolution anymore, only bug fixing, and software is thoroughly, extensively tested.

The updates for e.g. TortoiseSVN (which is probably very widely used) are bugfix+feature updates. And everyone gets a new version number and is official. I'd say they're about equal to CB's nightlies even with a similar frequency.

Your saying that TortoiseSVN's managed tested, formal point releases are the same as the nightly build dumps done here? Perhaps you should reconsider your statement. I'd encourage you to read two pages: http://tortoisesvn.net/downloads && http://tortoisesvn.net/status

Take note of the changelogs, release notes, nightly build policy, their release history-- Notice the alpha, beta, and RCs in there.

If anything, the CB user community would be far better served by following the TortoiseSVN release management structure. Sorry for being repetitive here. I wish responses to the logic of my suggestion were more prevalent than those dismissing it, or rationalizing the current SVN dumps.

[Zini]

If anything, the CB user community would be far better served by following the TortoiseSVN release management structure.

Why? Who cares if a new nightly suddenly has some bugs? It is trivially easy to go back to an older version.

TortoiseSVN is a totally different topic. For a start TortoiseSVN is rather "hard" to install. It inserts itself deeply into the system and even requires a reboot. If anything goes wrong here, that could be rather fatal.
But Code::Blocks? Okay, maybe some function will fail. That is hardly a drama. Going back to an older version takes at most two minutes (less, if you keep the older version installed in parallel).
And the chance for a data-loss or any other kind of damage is rather minimal too. Please note, that the embedded text-editor is a separate project, which AFAIK is going through a more ridigd release procedure. Adding to this any sane developer will use some kind of version control system, so even in the rather unlikely event, that some files are damaged, the damage would be limited to the work since the last commit.
Sorry, but worrying about the risk and the consequences of a malefunctioning nightly is extremly irrational in my opinion.

I would prefer it if the regular releases would be completely abolished. There are a waste of developer time IMHO.

[Willy1234]

I think that if C::B's nightlies are released as updates an update tool needs to be built into C::B  that is similar to the Mozilla Firefox one. Maybe also switching back to a standard version number convention (i.e. 1.x, 2.x, 3.x) rather than the Ubuntu version number convention. But what do I know, I'm just a user of the C::B nightlies not a dev. Oh and quick question, I just installed the most recent and I get a pop-up saying that wxSmithAui.dll was not loaded due to being an old version. Where can I get the newest build of that .dll?

[Loaden]

Crash Report:
1. Open CB and Close any page
2. View - Switch Tabs
3. Click 'Open files'
4. Crash!

Redo it.


[attachment deleted by admin]

[ollydbg]

Crash Report:
1. Open CB and Close any page
2. View - Switch Tabs
3. Click 'Open files'
4. Crash!

Redo it.

I can confirm this bug.

[Jenna]

Crash Report:
1. Open CB and Close any page
2. View - Switch Tabs
3. Click 'Open files'
4. Crash!

Redo it.

I can confirm this bug.

I can confirm it on w2k and linux, but it always crashes if I click on "Open files", egally if I have closed or opened any tab, even if no project is loaded.

I will look into it.

[Jenna]

Should be fixed in cc-branch (r5703) and trunk (r5704).

[Jewe]

The compiler settings(number of CPU for parallel build) are stored user depending and not machine depending.
I have a 4 core development machine, a 2 core laptop and a 1 core nightly build machine and all 3 machines have my profile.
can this be solved? so I can configure this for every machine independent?

cheers,

Jewe

[oBFusCATed]

No, because a user program can't change system files when the user is not an administrator (on all machines that != windows xp )

[Jenna]

You can use different personalities for different setups.
codeblocks --help shows the appropriate command-line parameters.

[Jewe]

You can use different personalities for different setups.
codeblocks --help shows the appropriate command-line parameters.

Thanks for the suggestion, but I still feel that it should be possible automatically.
Maybe its an option to have default, and a machine depended setting.
where the machine depended parameter is the ID of your CPU or something.