1889 - Substitution Token for TOC Interface Version
(I thought i already suggested this - but couldn't find the ticket)
What is the enhancement in mind? How should it look and feel?
## Interface: @InterfaceVersion@
Allow specification of supported interface versions (plural) via the web interface.
This would avoid the bazillion TOC bumps on a patch day - plus its 'opt-in' by nature (since you have to deliberately add it).
Also it allows you to specify that your version works on the PTR in advance of patch day.
I realize that the actual solution would need to allow the working copy to show a valid version as well.
Perhaps add support in the #@debug@ / #@end-debug@ to handle toc keywords by prepending X-, as well as #@no-debug@ / #@end-no-debug@ tokens.
In a working copy
#@debug@
## Interface: 30000
#@end-debug@
#@non-debug@
## X-Interface: @InterfaceVersion@
#@end-non-debug@
In a packaged zip:
#@debug@
## X-Interface: 30000
#@end-debug@
#@non-debug@
## Interface: 30200
#@end-non-debug@
Or something cleaner...
Then in the web interface have checkboxes for each interface version (adding new ones as they become relevant).
- 3 comments
- 3 comments
Facts
- Last updated on
- 05 Feb 2010
- Reported on
- 06 Oct 2009
- Status
- New - Issue has not had initial review yet.
- Type
- Enhancement - A change which is intended to better the project in some way
- Priority
- Medium - Normal priority.
- Component
- Packager
- #3
Zasurus Sat, 06 Feb 2010 01:46:01I think you are correct in that something needs doing about patch day but I think your method is not the right way to go about it.
I believe the TOC file should remain hardcoded as that is what version THIS version of your addon has been tested on…
It's there for a reason and I also believe you should use it like it is meant to be used. If your version hasn’t' been tested for the new version then it is a beta (or alpha) so only people who want to take the risk and voluntarily download the beta/alpha test it and people who don't know what beta's are or don't want to take the risk of ruining there raid night because your addon goes tits up on the last boss have the old version automatically disabled by the patch (which is why it does un-tick the load out of date addons for every new patch). :-)
ALTHOUGH I DO believe that the current way we deal with patch days is in-surfactant and does cause a panic of patching AFTER the faeces has hit the fan (everyone has the old addon and the new patch so they stop working).
I have proposed a better way in another ticket: http://www.curseforge.com/projects/curseforge/tickets/2178-suggestion-to-solve-the-problem-of-patch-day/
Thought I would try to explain why I think everyone will vote -3 to this ;-) Hope I didn't offend you as I LOVE so many of your addons! :-D I can't live without Prat 3.0! Keep up the good work
Zas
P.S. I HAVE read this ticket before and it had -3's all on it then so I guess you got voted into the bin last time as well ;-)
- #2
Ackis Tue, 06 Oct 2009 20:52:48I voted a -3 for this. The ToC is meant to state which game this works for, etc... the ToC changing on patch day isn't a huge issue IMO.
I'd rather stick with the hard code ToC than run into the issues associated with auto-updating it.
- #1
sylvanaar Tue, 06 Oct 2009 13:45:50Admittedly this is more useful for addons which work on multilple interface versions.