I tried to avoid this thread as my comments could do some damage (coming from someone who is trying to promote the project). However, honestly is always the best answer so here it goes:

raph did contribute an update script which was later thrown away. Why? I don't know. What we need is a simple update method (automatic or manual) that could take people from Build A to Build B. It doesn't have to be very complicated. Drupal for example does the automation beautifully meanwhile vBulletin does the manual job beautifully. We can start by posting a thread with "Changes from Build X to Build Y" and listing any alterations required. That way, us testers don't fall too much behind when we're testing each build and those of us who decide to use a latest build for their production site could go on using the bleeding edge code on their server in peace. I personally decided to use the latest build on a production environment. I rather use the latest code and risk having my server hacked than use RC2c and face an unstable panel. That's how much faith I've put into the latest build! It is a measure of how much work has gone into it by the devs. I am certain many of our members are doing the same thing!

Now lets settle some of the arguments put forward here. Do you agree that majority of ispCP users are web hosts? Do you agree that majority of web hosts are making money from this software? If they don't have time or knowledge to follow manual upgrades, they can pay an experienced sysadmin to carry out the manual upgrade for them. We can even put RatS, ephi, ralph and jox for the job as PAID SUPPORT! There needs to be a commercial element in this project if we want the big corporations to use it. Not necessarily for the money, but just to provide the necessary assurances and guarantees that there are experts who are available if and when required.

I want to see more leaders on board this project. The last thing I want to see is the unity and community we built here the last 12 months destroyed because of another fork. We need to work together because there's strength in numbers. I understand joximu's point trying to cure a problem with his script and Ralph can improve on the idea further. I also understand Ralph's point when he decided a few months ago to add Trac comments during his commits to inform us whether his changes will break things or not. They are both actively trying to cure problems they are facing.

There should be a private poll with a fixed duration in the "secret" dev forum where all devs and project leaders vote. The outcome of this poll decides which direction the project takes. Keep it democratic and sensible. If you're unsure about a feature, ask the community. E.g. "Would you like to see an update script from RC2 to RC3 in return for a 2 month delay?". Based on the feedback, make the next move. Recruit more people and eventually the project will automatically run itself and decides it's own fate. I'm tired of hearing about the upgrade script excuse. What if this upgrade script lands too late? Do you *really* expect VHCS people to migrate to ispCP RC3 when there are better opensource alternatives out there? VHCS is already dead and right now ispCP is dying too.

IMO, RatS and ephi are great developers, but they may not be great project managers or community leaders. This is your baby, and as such you need to ensure it's survival. Ask yourself, if you can't devote 1 day per week on this project then maybe it's in the project's best interest to let another person take your seat? Don't let the word "control" be the last thing that kills this project. Imagine the irony!

I'm not going to apologise for the long post, but I will leave you with actionable suggestions so we can resolve things around here:
1) Release ispCP RC3 based on current build. State that upgrade instructions will follow.
2) Write or update our documentation for moving from ispCP RC2c to RC3.
3) Write documentation for going from Build X to Build Y for every build that gets released after RC3.
4) Release ispCP RC4 by following 1 (above) and let the cycle continue until v1.0
5) Release ispCP 1.0 and promise an automatic update script for future builds.
6) Start writing documentation for migrating from VHCS 2.4.7 to ispCP 1.0. Let's survive to 1.0 then worry about bringing VHCS guys on board.