Author Topic: Suggestion Regarding Version Numbering/Releases  (Read 6066 times)

Offline BigAngryDog

  • Multiple posting newcomer
  • *
  • Posts: 75
    • BigAngryDog.com
Suggestion Regarding Version Numbering/Releases
« on: July 15, 2006, 04:53:19 pm »
Hi there,

This is only a suggestion - so feel free to shoot me down.

Currently, releases are called RC1, RC2 etc. Presumably, RC stands for "release candidate". However, the releases do not appear to be release candidates, rather they are "alpha releases". Would a better versioning system not be along the lines of:

major.minor.patch

A transition to this system could be quite smooth, and the upcoming RC3 release could be designated: 0.3.0, and the "final" release after that could be 1.0.0.

In addition, there is a lot of excitement about CodeBlocks at the moment and people are anxious to get their hands on RC3. While many people use the nightlies, many others prefer to stick with a so called "stable" release. And because the main webpage has not changed for so long, others may be wondering whether anything is happening at all.

IMHO the time to strike with RC3 is now, and the current code base should be released as ASAP - without delay due to adding new features or tweaks. The current C::B is [more than] good enough for a pre-release release. There would be plenty of time to deal with outstanding issues and add features between RC3 and the "final" release.

Just my thoughts :)
BigAngryDog.com

Offline Der Meister

  • Regular
  • ***
  • Posts: 307
Re: Suggestion Regarding Version Numbering/Releases
« Reply #1 on: July 15, 2006, 05:18:23 pm »
Just take a look at many threads about this in the forum. There are very good reasons why RC3 is not yet released. The main thing is: It will be feature-complete. That implies that major changes (especially changes of the sdk) are not possible any more up to the 1.5 release. And this probably wont be in the near future. Thus these changes have to be done *before* RC3 is released.
Real Programmers don't comment their code. If it was hard to write, it should be hard to understand.
Real Programmers don't write in BASIC. Actually, no programmers write in BASIC, after the age of 12.

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9508
Re: Suggestion Regarding Version Numbering/Releases
« Reply #2 on: July 15, 2006, 05:28:58 pm »
This is only a suggestion - so feel free to shoot me down.
Not really, but did you do a forum search on that topic before you posted? :lol:
You are number 19473526174858 asking this question (me included in the "old" days ;-)).
With regards, Morten.
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: http://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: http://wiki.codeblocks.org/index.php?title=FAQ

sethjackson

  • Guest
Re: Suggestion Regarding Version Numbering/Releases
« Reply #3 on: July 15, 2006, 07:53:49 pm »
Besides the above, the new build system (compiler framework) isn't finished yet AFAIK....

Offline Game_Ender

  • Lives here!
  • ****
  • Posts: 551
Re: Suggestion Regarding Version Numbering/Releases
« Reply #4 on: July 15, 2006, 10:14:34 pm »
I agree with BigAngryDog on the version number issue.  I posted about this here, but this post is much more on topic in this thread so I will repost it:

"I think the problem is with the version number scheme, it has gotten everyone confused.  Release Candidates are just that, a build which could pretty well become the final build for that version, ie the checksum of the RC3 should/could be equal to the checksum of 1.0 final.  It appears as if mostly bug fixes are going into the trunk right now, so we are doing pretty good.

I think CB is going to be one of the version number jumping products (not really a bad thing), after all the next version is already called 1.5, which means the release after that will most likely be 2.0.  Frankly I like the way the linux kernel does things with number like: Major.Minor.Bugfix.  You only a new major version if some massive interface breaking changes comes along with a large rewrite or the project.  Minor versions alternate between unstable and stable.  For example the next develpement version of CB would be 1.1.0 only while it was being developed.  After it finished, it would become 1.2.0.  The Bufix part of the number is for any changes or bugfixes that don't break the interface.  In our example you get 1.2.1, 1.2.2 etc.   These number don't roll over after you get to 9, so its perfectly ok to have 1.11.13.  This is also pretty close to how GCC does there release scheme, although I don't think the do the stable/unstable thing for the Minor version number.

No matter how logical the above the is, its still opinion and not a rule.  Many projects, especially those more oriented to users like to jump the version numbers.  Firefox has been doing that recently with it's skip up to 1.5 and soon 2.0.  Code::Blocks is great project and the more I use the more I like it.  I think plenty of people here want a good stable 1.0 release that they can develope some good pluggins against.  That is why the CB team is working so hard to make sure they get this release right."

I now realize it should be major.minor.patch, not major.minor.bugfix.

Offline BigAngryDog

  • Multiple posting newcomer
  • *
  • Posts: 75
    • BigAngryDog.com
Re: Suggestion Regarding Version Numbering/Releases
« Reply #5 on: July 17, 2006, 10:27:27 am »
>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
BigAngryDog.com

Offline android_808

  • Single posting newcomer
  • *
  • Posts: 4
Re: Suggestion Regarding Version Numbering/Releases
« Reply #6 on: July 17, 2006, 11:22:12 am »
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.

Offline BigAngryDog

  • Multiple posting newcomer
  • *
  • Posts: 75
    • BigAngryDog.com
Re: Suggestion Regarding Version Numbering/Releases
« Reply #7 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.
BigAngryDog.com

Offline kidmosey

  • Multiple posting newcomer
  • *
  • Posts: 95
    • MUSITU International
Re: Suggestion Regarding Version Numbering/Releases
« Reply #8 on: July 17, 2006, 12:15:03 pm »
>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.

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

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.

I like the idea of rating the stability of nightly builds and listing the most stable snapshots on the main page.
3 years until google knows more than god.

Offline BigAngryDog

  • Multiple posting newcomer
  • *
  • Posts: 75
    • BigAngryDog.com
Re: Suggestion Regarding Version Numbering/Releases
« Reply #9 on: July 17, 2006, 12:28:29 pm »
>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. :)
BigAngryDog.com

Offline thomas

  • Administrator
  • Lives here!
  • *****
  • Posts: 3979
Re: Suggestion Regarding Version Numbering/Releases
« Reply #10 on: July 17, 2006, 01:28:16 pm »
Quote
New versioning scheme of major.minor.patch
Well, basically we almost have such a numbering scheme. The old "official" release was 1.0 RC2, so there is major.minor RC-SUFFIX. You could also say we had a patch level once as in 1.0 RC1-1. The problem is not the numbering scheme, the problem is that we have moved to RC too early once, which we cannot take back.

Quote
Actually, I think the RC3 terminology is what is confusing everything,
The problems with revision numbers and releases are well-known to us. We have discussed what to do to get out of the Dead Marshes alive many times, and we agreed that following our guide, whilst knowing he will lead us to evil, is the lesser risk.

Some things really did not work right in RC2, and RC2 was quite unusable in many respects. We still have a non-working code completion today.
From this point of view, one could argue that technically, we are going through RC stage because we fix things that don't work. However, it is quite obvious that this is not true :)
Yes, we have been adding many features and we still are. This should not happen at RC stage, and we know it. The correct thing would probably have been to call the next upcoming release alpha-6 or alpha-7.
However, the evil that comes with changing the version numbering is still greater than the evil of going on as before (or so we believe). We would not want to confuse the users yet more by jumping forward and backward in time with our releases.


Quote
2. Intermittent alpha releases
I am against intermittent alpha releases (and so was Mandraman when we last talked about this) because it will probably lead to even more confusion and yet more problems.


@BigAngryDog: Hey, you wear the same kind of stupid-looking hats as I do! Very cool :)
"We should forget about small efficiencies, say about 97% of the time: Premature quotation is the root of public humiliation."

Offline BigAngryDog

  • Multiple posting newcomer
  • *
  • Posts: 75
    • BigAngryDog.com
Re: Suggestion Regarding Version Numbering/Releases
« Reply #11 on: July 17, 2006, 03:43:42 pm »
OK. You guys have already thought about this.

I look forward to getting my hands on RC3 (and the official release) whenever they are ready. :)

>Hey, you wear the same kind of stupid-looking hats as I do! Very cool

LOL!  :lol:
BigAngryDog.com

Offline android_808

  • Single posting newcomer
  • *
  • Posts: 4
Re: Suggestion Regarding Version Numbering/Releases
« Reply #12 on: July 17, 2006, 08:13:51 pm »
I like the idea of rating the stability of nightly builds and listing the most stable snapshots on the main page.

Maybe this is something that could be done through a topic on the forum or wiki rather than posting it on the main page.  The people using these would more likely be following the development of the application, wanting to try the new features whilst maintaining a stable enough environment as apposed to those who would only rely on the final releases because of the inherant stability.

I haven't used this forum much before, but can it do polls?  If so why not make the nightly release page include a poll with stable/unstable as the options.  You could do a few tests using ordinary posts before adjusting the nightly pages.