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.

BioALIEN Wrote: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.

Agreed, a way that people can confidently go from RC2c to the latest build.

Quote: 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!

I'm more than happy to move to the latest build, but I just don't feel confident of getting all the details/modifications done from nightly build to nightly build up to the latest nightly build.

Get those "Changes from Build x to Build Y" documentation done, and I'm sure we'll eventually get everyone up to the later builds.

Those of us on the old RC2c are wasting our time putting in bug reports, because they've been umpteen dozens of builds done since there, and what we find in this version is totally different to the current ones.

Quote: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.
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.

Damn good suggestions there... get a RC3 out to the masses of RC2c users, with hopefully upgrade instructions.

Any of us running RC2c will no doubt upgrade to RC3, and then finally we'll be able to start to report current bugs, rather than ones that have long since been resolved.


I believe Release Candidates should be no more than 2 or 3 months apart, and this current long gap is hurting us all.

I think that the main developer is a smart guy, he is pushing for this upgrade/migrate script in order to gain more testers for rc3... so all you guys will get busy fixing the new discovered bugs in rc3. Because without testers to report bugs the wait for rc4 will be even longer than current wait for rc3.

On the other side i personally believe that even rc1 was not really rc1... it was public beta if not even an alpha release... you decide to call it rc1 because it is supposed to stay on a somekind of stable base (rem. VHCS) but VHCS is not stable ether.

However, my suggestion for you guys in order to move on is following:
- Get rid of any upgrade script
- Find 10-15 seriose testers (start topic in the forum "testers wanted")
- Install from scrach and test until 1.0

After 1.0 start spending time for upgrade scripts and so on.