User forums > General (but related to Code::Blocks)

Suggestion Regarding Version Numbering/Releases

<< < (2/3) > >>

BigAngryDog:
>You are number 19473526174858 asking this question

I don't believe I asked a question. Rather, I was making a suggestion. Personally, I'm not in a desparate hurry to get my hands an RC3 or final release - I'm happy using RC2 and nightly builds.

In any case, I have no right to expect or demand a release. Rather I'm saying that people need to know that something is happening and be given something in terms of a next release. I've spent many years developing projects of my own, only to see them wasted, partly because I was so wrapped up in perfecting the source to my own [impossible] specifications that I failed to communicate with potential users.


>There are very good reasons why RC3 is not yet released. The main thing is: It will be feature-complete.

Feature Complete is open ended. A month back, I was awaiting the release of RC3, which I believed was a few days away, but couldn't help noticing new features being added to nightly builds. How will you know when all the features have been added?

However, I understand there need to be some major changes and these should be done prior to an official release. So...

Why not have an "Alpha Release 3" now and then a true release candidate a month or two before the final official release?

CodeBlocks is a potential VC killer! So come on guys! Get something new on your front web page and let people know about it! :)

Best wishes

android_808:
I think some people have forgotton the principles of a "Release Candidate".  It should literally be the final testing stage, looking for any bugs before the final release is made.  If any bugs are found and fixed, then a new release candidate should be, well, released.  There should be no changes between the last release candidate and the final, stable release.

What I think everyone is looking for at the moment is a testing and bug fix phase on the current code base in order to release a stable development snapshot.  I wouldn't call it a "Release Candidate", I would just call it the latest stable development snapshot.  I know this would slow down the actual development a bit while all the bugs were fixed, but it would then allow you to start working on a code base that is stable.  Imagine you add a new, super-duper feature everyone uses only to find that when a bug is fixed somewhere else it breaks the new feature.

Hell you could just rate how stable the nightly builds are and have a link on the main page to the latest nightly that had the fewest bugs/was the most stable.  Kind of like the development releases of GIMP 2.3 compared to a CVS snapshot.

BigAngryDog:
>Hell you could just rate how stable the nightly builds are and have a link on the main page

There is no installer with these, nor is there any confirmation that they are stable.

kidmosey:

--- Quote from: BigAngryDog on July 17, 2006, 11:59:20 am --->Hell you could just rate how stable the nightly builds are and have a link on the main page

There is no installer with these, nor is there any confirmation that they are stable.

--- End quote ---

So then couldn't it do more harm than good to supply a pre-release or to rush RC3 if it isn't "stable"? 
Edit: Actually, I think the RC3 terminology is what is confusing everything, so you may be right that a new versioning system is in order.

There is a link to "developer snapshots" on the main page just below RC2, and it hints that they are more-or-less stable, which is really the only guarantee they can make, at the moment.

As far as an installer is concerned, it is feasable to include an installable version of the nightly builds (with a disclaimer of stability).


--- Quote from: android_808 on July 17, 2006, 11:22:12 am ---Hell you could just rate how stable the nightly builds are and have a link on the main page to the latest nightly that had the fewest bugs/was the most stable.  Kind of like the development releases of GIMP 2.3 compared to a CVS snapshot.

--- End quote ---

I like the idea of rating the stability of nightly builds and listing the most stable snapshots on the main page.

BigAngryDog:
>Actually, I think the RC3 terminology is what is confusing everything,

Yes. I agree.

To summarize, the suggestions are:

1. New versioning scheme of major.minor.patch, where current RC releases are to be known as alpha releases (or similar).

2. Intermittent alpha releases (but more frequent than current RC releases).

3. Latest alpha release download available from front page.

4. Final release available when good and ready. :)

Perhaps we could take out a full page advert in an appropriate newspaper/IT journal when the final release is ready - just like what Firefox did. I'd be willing to make a donation toward this. :)

Navigation

[0] Message Index

[#] Next page

[*] Previous page