vBulletin version 3

[Steve Machol]

Originally posted by Radon3k
Might I suggest the Hack Anticipator Engine® with built in Auto-Upgrade support?

Yeah, but who can afford that? $999.00 for a site license is out of reach for most of us!

[Skeptical]

Originally posted by smachol
Yeah, but who can afford that? $999.00 for a site license is out of reach for most of us!

Or how about a "Money Making Engine®" to go with that so we can pay for the other upgrades?

[chrispadfield]

Originally posted by Skeptical


Or how about a "Money Making Engine®" to go with that so we can pay for the other upgrades?

That is an interesting point. I imagine all of you have had emails from people concerned that by using your site they might be charged, generally people from AOL who paid per hour for access to content. Well you can stop reassuring them that they have to hand over the credit card details to actually pay anyone because we have finally found a way to charge people to use your forums without them even knowing. This feature is very important to the developers because it provides a guranteed way for you to make money using vbulletin and we believe you are thus far more likely to buy further licenses.

We have not patented this process yet but I believe after Martins recent blunder of mentioning a product before it was trademarked that he is on to the case to get that sorted.

[Faruk]

Originally posted by Martin
That would require writing an upgrade script to check for every hack imaginable, and convert it if it's added as a feature.

I wouldn't hold my breath on that. The upgrade script would be larger and more server intensive than the program.

Well, you could have a partial one, I would say. As we've seen in the changelog that PPN posted on vb.org, the upgrade from 221 to 222 could be done by simply adding/altering parts of certain pages. I can't imagine that you couldn't write a script to do those things.

The 'normal' way of upgrading is overwriting all the files from the new download and running the upgrade script, is it not? Why not have an upgrade script that adds the new coding to the right place, and give an error if a hack messed up part of the integral coding, or something alike?

[NetherChris]

The problem with that is (someone correct me if I am wrong) is that with php's ereg_replace or something similar, you would wind up having to write an ereg statement for every single line or paragraph that needs to be updated. There isn't a really easy way to "fill in the blanks" for spots that the hacks could be inserted...

it could take longer just to write the upgrade program than vb3 itself if that was to be done.

[joebob]

sorry to change the subject, but anybody know when VB 3 will come out?

[John Round]

Originally posted by Skeptical


Leads to some pictures of John in his underwear writing php code.

Correction:Leads to some pictures of John in his Mr Men underwear

[JamesUS]

Originally posted by 1337Devil


Well, you could have a partial one, I would say. As we've seen in the changelog that PPN posted on vb.org, the upgrade from 221 to 222 could be done by simply adding/altering parts of certain pages. I can't imagine that you couldn't write a script to do those things.

The 'normal' way of upgrading is overwriting all the files from the new download and running the upgrade script, is it not? Why not have an upgrade script that adds the new coding to the right place, and give an error if a hack messed up part of the integral coding, or something alike?

Not going to happen as that would require all of your vBulletin files to be chmoded to 755 - and I and many others moved away from other languages like Perl because of the inconvenience of chmoding.
Also as was said above, to do that without breaking hacks would take weeks to write each upgrade script and would take far too much valuable development time. As it is, it only takes a few minutes to do an upgrade script.

[AWS]

Wouldn't require that at all. They would have to chmod 666 which is the default when you upload a file anyway on most servers and if its 644 instead then a simple shell command will do the job to change permissions on all files.. 755 gives +rw 666 gives rw. Also depending on where you host some chmod 755 on all files on upload. My old host did that.
Anyway I think that would be a nice feature to add.

[tubedogg]

If you would like the release of vB3 to be postponed by several months (read: release in September/October instead of April/May) while we work out the upgrade script...

It's not going to happen.

[JamesUS]

And if any of your hacks modify the lines that the upgrade wants to modify, your hacks would become corrupted. While we may well come up with a better way to upgrade than the current method of lots of upgradex.php scripts, it certainly will not be able to preserve your hacks for you.

[wanders]

Originally posted by Martin
because we can't anticipate every hack that will ever be written, and most hacks will require certain placement within the file(s) in order to work right.

gee, martin, some company you're a part of here! "can't anticipate every hack that will ever be written." well certainly not with THAT attitude!

[tubedogg]

Even assuming we knew every hack written, it wouldn't be pheasible at all. Firstly as mentioned a bunch of times it would take many weeks or months to create which is a complete waste, and secondly, it wouldn't work on my forum, for example, because almost every hack I've done on it is unreleased and ( ) undocumented.

[Skeptical]

Create a Hack Integration Engine and add plugins into it. Create some sort of API that hack coders can follow to easily plug into this engine.

[chrispadfield]

Originally posted by Skeptical
Create a Hack Integration Engine and add plugins into it. Create some sort of API that hack coders can follow to easily plug into this engine.

This has been discussed in fact but the belief is that it would make the program much more inefficient. For example you would need to create hooks for almost every action in vb, the problem is there are so many options - it is not like a link directory script where plugins are a sensible way to manage hacks becuase there you can basically add/delete/edit/search and that is about here, with all vb options you would need a lot of these hooks. Then you have to have resources to check each hook for various options and add to that that the generic sql queries would have to be more general to return every feasible result that might be used in the "plguins" you would end up with something very inefficient.

Generally a plugin system makes creating hacks far more complicated as well. If you have a look at www.gossamer-threads.com which do have this sort of plugin system, they have a very inactive hacking community with very few hacks created compared to vb.org. Part of this is probably due to the complexity of using the plugin system.