2178 - Suggestion to solve the problem of patch day
This is my suggestion to solve the problem of patch day. I am really only offering an alternative to Sylvanaar’s ticket: 1889 - Substitution Token for TOC Interface Version as I agree with the problem but not his solution. :-)
Quick summary of the situation as I see it:
As I see it the problem is that on patch day everyone’s addon's go down because they are now out of date and blizzards patches disable out of date addons to prevent errors. This is a deliberate thing by blizzard to prevent the average player from opening LOADS of tickets to the GM’s saying that there patch broke WoW when in fact it is just the addon’s they are using are not out of date! The way blizzard want you to do it is test the patch in the new version and then when you know it’s ready you update the TOC file to the new version and put it live. The problem with this method is that as mentioned earlier everyone’s addons get disabled on patch day, the users complain and the addon developers rush to test them and put fixes in quickly… Everyone gets stressed and dreads patch day!
Detailed problems and my suggestions for solutions:
Problem 1:
Lets go to the last problem there… all the addon dev’s play catch up as ether they didn’t know that the patch was coming out or didn’t know the PTR server was open so didn’t test there addon in there. So the problem is that most developers play WoW as well as working a full time job (likely as programmers etc…) so don’t have time to check for info on the new patches and when they come out so are court out without checking there addons work with it (at least I am always told by my better half as I come home from work that a new patch is out and she is getting xxx errors now)!
Solution:
As soon as blizzard announces the new patch is in testing and what changes is in it Curse could email the active developers (maybe this could be an option that they have to opt into or out of) with this information including a link to the list of changes! This would give the dev’s a heads up to fix the problems at there leisure!
Problem 2:
*This now leads on to the problem that you can’t really get these files out to the testers for the PTR as you can’t mark the file as ready for a version of the game that isn’t LIVE yet…
* = I am not sure this is really a problem as I haven’t tried! I AM GUESSING IT’S A PROBLEM AS I HAVE NEVER NOTICED IT YET! If you ca already do this just ignore this problem and move on to the next one! LOL
Solution:
Have a special option in the “Files” tab on CurseForge.com under the “Game version:” for the PTR or upcoming game version that this addon version is for. E.G. the current live game version and the highest version you can say your addon is ready for is “3.3.0” say blizzard announced that the next patch was going to be “3.3.4” and that the changes for the API where a,b & c and the PTR is open tomorrow (Sorry if this is crap I don’t keep track of how this stuff works! ;-)), another option should then be added to the top of the “Game version:” for “3.3.4 - (Testing only)” or something like that…
Problem 3:
Finally the developers have managed to test/fix there addon’s for the new patch BEFORE it has come out… but they would still have to wait until patch day to post it otherwise LOADS of users get the opposite problem and the curse client automatically downloads the updated version 3 days before the patch is live causing there addon to go mad in the middle of there Raid anyway!
Solution:
This is where the “special option” from Problem 2’s Solution section is so special… it the Curse Client ONLY updates your version of wow if you are running that version of the Game (the website would need some way of getting it manually maybe)! This would be for people running the PTR version before the patch is released live and on patch day (maybe when the server is taken down to add the patch the night before) it would update/allow every else to have the update…
OK I THINK that is all I have… Hope I am not the only one that thinks this is a good idea! :-) Please add your own suggestions below and I will update this as they come in. ;-)
I do understand that this is going to be a BIG change! BUT I think it is the only one worth doing… it won’t be noticed by the average person as they don’t need to do anything extra, the developers get more time and more info to make the changes required for there addon’s to continue working straight though the patch and if they choice to ignore it… well their experience of Curse.com and CurseForge.com / addon development won’t change! :-) I can only see the disadvantage of development time for the curse team! Sorry guys! BUT this would take your site ANOTHER step above the rest! I already put my addon’s on curse exclusively due to your advanced development and deployment tools and this would be another reason… NO PATCH DAY DISASTERS! ;-)
Finally once someone marked there addon’s as ready for deployment maybe the curse client could allow them to be downloaded in advance of patch day and kept safe ready to install on patch day saving the hit on your site from everyone updating? ;-)
Regards,
Zas
- 6 comments
- 6 comments
Facts
- Last updated on
- 04 Dec 2011
- Reported on
- 06 Feb 2010
- Status
- Declined - We decided not to take action on this ticket.
- Type
- Enhancement - A change which is intended to better the project in some way
- Priority
- Medium - Normal priority.
Reported by
Votes (Total: +9, Average: +3.0)
-
Votes +3
-
Votes +3
-
Votes +3
- Reply
- #6
BigRedBrent Sun, 21 Nov 2010 13:58:35@Zasurus: I agree that a notification of possible addon breaking changes would be handy, as long as a developer may unsubscribe from it. I personally would find it very useful if I decided to stop checking for update changes myself.
Check out the addon SpellFlash to help improve your gameplay in World of Warcraft!
- Reply
- #5
Zasurus Sun, 21 Nov 2010 11:48:07BigRedBrent: I think this problem would def be much smaller if that multi toc was done but I think solution 1 would still help keep addons upto date. For example if the multi toc num was added (that would be nice!) and curse sent out an email saying PTR is up... these are the current known changes you need to worry about go check/fix stuff. Then they could look over the api list if it is something they dont' think will affect them they can do a check in the PTR to make sure it all works then update the TOC to the new interface num and forget about the addon until next patch :-)
Right now if they don't watch the sites they won't know about the patch until they log in and get loads of tickets or find they need to update there client and all of a sudden there addon doesn't work...
Don't see how this can do harm (mind you after reading how anal ppl can be just because... *cough* Thunt from that post *cough* I am not sure what to thinik! ;-)
Although you are correct that a lot of these issues could be solved by having two or more valid toc numbers :-)
- Reply
- #4
BigRedBrent Sat, 16 Oct 2010 19:56:45This wouldn't even be necessary if Blizzard would add an extremely simple fix on their side: http:forums.worldofwarcraft.com/thread.html?topicId=26850279128
- Reply
- #3
Mavoc Tue, 11 May 2010 05:30:23been awhile since i played WoW, but I remember an option in WoW's addon section that let you turn off the option to olny load addons that support the current version. did they remove this option and if they did, how hard would it be to make an overwrite xml/lua files to re-enable it
- Reply
- #2
Speeddymon Mon, 26 Apr 2010 20:33:11I'll support this one as well. Oddly enough I was thinking about this earlier, but then remembered the problems with automatic bumping and dismissed the idea. Then lo and behold I run into this ticket.
The way I see it, sylvanaar actually explained it better though, most people just didnt understand what they read and gathered "auto bump toc"..
What I read is this:
-Checkbox on website with client versions
-X-Interface in TOC with PTR version number, probably wrapped in one keyword
-Interface in TOC with Live version number, probably wrapped in another keyword
-On patch day, tick box on website to enable the new version number.
Looking at the current keywords, this is almost possible right now.
#@do-not-package@
# Whatever is here stays in working copy but gets removed during packaging
#@do-not-package@
Could add a new keyword @ptr-interface@ @end-ptr-interface@, like below:
Working Copy:
#@ptr-interface@
## Interface: 30300
## X-Interface: 30400
#@end-ptr-interface@
Packaged:
## Interface: 30400
What it does is reads the X-Interface line and moves the number there to the Interface line, then removes the X-Interface line, and probably the keyword itself, from packages. This is a quadruple failsafe for these reasons:
1) The developer would have to opt into using this system by adding the keyword
2) The developer would have to update the X-Interface with each new minor PTR, so if they do not, then the packager continues to use the (for example) 30400 interface that's listed on the X-Interface line.
3) The developer would need to tag their repository after adding the keyword, and after each increase in the PTR minor version number.
4) The developer would also still need to check the checkbox on the website on patch day to activate the keyword in the packager, meaning that until Kaelten or ckknight or Ackis, etc, adds the new version to the database, the developer can't utilize it anyways.
It would have to be documented that the format needs to match or else it won't work/may cause bugs/etc. There are other ways it could be done too, all of them still requiring developer intervention so NOTHING gets -automatically- bumped by accident.. It would be something that definitely a majority need to agree on, no matter what.
- Reply
- #1
sylvanaar Mon, 22 Mar 2010 05:25:01This is pretty much what i was suggesting - web interface for describing toc version compatibility and matching client functionality.