The Arcive of Official vBulletin Modifications Site.It is not a VB3 engine, just a parsed copy! |
|
#1
|
|||
|
|||
Releasing Updates for Mods to 4.x
Ok so I can understand the announcement about the update notifications. But what is the actual update procedure? i.e. Releasing your own updated mods from 3.x to 4.x.
The actual mod I'm working on is finished and pretty much ready for release but it's this release step which I am unsure on when it comes to re-releasing my own mod. Now at the moment as I have updated my product rather than start from scratch, the product id is the same and surely for people upgrading that would need to be the case? As it would need to overwrite the old plugin i.e. ppl shouldn't have to uninstall the old version (lose all their settings in the process) and then install the new one. So how should I go about this? This will be the first time for me releasing an updated version (on a different series) of my own mod. Sorry if there's already an article/thread that answers this question but I couldn't find anything from my brief look and I'm a bit perplexed on how this should be handled. After taking a look at one of Paul's mods it seems he used separate product id's but what about the issue with install/uninstall code adding/removing extra fields? Surely people uninstalling the old version would remove database fields that are added on the install. Shouldn't the upgrade process be as simple as possible for everyone? |
#2
|
||||
|
||||
I give each new release a new product id suffixed with the vb version its released for (e.g. xxxx_40) I then use a little piece of installation code I wrote that removes older versions of the same mod (based on productid) when you install the new one, therefore the update procedure is simply to install the new version (not uninstall the old one first). Due to the way the vb install system works, this does not remove any data from the old mod as the uninstall code isnt run. It also appears to preserve settings (as long as the setting name has not changed).
|
#3
|
|||
|
|||
Ah so you just run a mysql query to delete the old product (below)? Or do you do something a little more advanced than that (though I can't see what else you'd really do)?
i.e. DELETE FROM product WHERE productid = 'xxxx_10'? I hadn't thought about that at all. Sounds like a good solution to me. Though it does seem a little strange to me that we have to release them as separate mods. Especially between sub versions when much isn't changed. i.e. 3.6 and 3.7. Also is it general practice to re-release mods for new versions of vB even if the old version of your plugin still works? i.e. If they came out with 4.1 next month and my current mod still works is it normal to re-release the exact same product just for the new version or do people leave things as they are and add a note to the current release saying that it still works for that version of vB. |
#4
|
||||
|
||||
Quote:
Quote:
Who knows what we will do for 4.1, I think it will be a while before we need to worry about that. |
#5
|
|||
|
|||
Do share . Obviously I know that there'd need to be more than what I just posted to actually do the query but it'd be worth knowing if there's more that could/should be done than just calling a query. I guess I'll just sneak a peak at one of your products :P.
Quote:
|
|
|
X vBulletin 3.8.12 by vBS Debug Information | |
---|---|
|
|
More Information | |
Template Usage:
Phrase Groups Available:
|
Included Files:
Hooks Called:
|