Until some type of upgrade feature is decided upon, I have a question regarding the [start] / [end] changeid comments added to the file / template mods...

Are the changeid's dynamically generated from the sort order of the edits? Reason I am asking is say that someone makes an updated version, uploads the updated version, but also wants the people that had installed the hack prior to the upgrade to be able to get the goods. *IF* the only chnages were to the files (i.e. - new / changed) and / or changed templates, the previously installed users should be able to upgrade via uploading the files and the "Install" of the new .HTL and choosing "only import info". Then go into the file / template edits for the and make sure each one matches and / or add / change the new / changed ones, right? The problem that I forsee with this type of "upgrade" (until an HTL upgrade feature is there) is that if the changeid's are dynamically generated, the "old" changeid's may not match the "new" ones and that would make that option a little more confusing... I was just wondering, since I hope to finish my Spell Check hack soon and am contemplating releasing it on vb.org. Since it is my first hack, I will probably be putting it in the "beta" section, and will probably need to "patch" it a few times...

They're currently dynamically generated. Once we have display order # for file/template edits, the changeids will be using that number instead.

So as of HTL 1.1 it won't be 'random', it'll be the display order as chosen by the hack maker.

Will I be able to turn these tags off for certain edits?

They won't be very useful if I'm having any edits inside of querys, (HTML-)outputs and so on. And no, I don't plan on asking a user to replace a huge query for example, when only one line has to be changed or added. ;) Why? Simply when vBulletin edits one of these queries the change would become invalid and I have to apply the changes to each affected step.

If vB changes a query the chance is fairly big you have to revise your edit(s) anyway, and if not it's better to change/update your hack than to say it's forward compatible "because you only changed one line of a large query" for convenience.

So there's no chance to have any edits without these tags :/ They're even in template-edits.

I'm not entirely happy with the tags either, even though they have the sole benefit of quickly finding changes again...

Yes, IMHO you should either have the chance to choose SQL and use SQL-Comments '### ', ' ###' or no tags at all. (I guess the latter would be the approach for SQL-Edits)

Like stated above, SQL edits should be made as a whole, not as a fraction. I know that in some cases it's not as conveniant, but it's more reliable.

Whatever. Why won't it be possible to provide a choice to have edits without the tags? There will definitely be reasons for having edits without them. e. g. many small edits, inline SQL-Edits (and I disagree with you about that point) many small Template-edits among others. A bit more flexibilty would be nice IMHO.

A bit more flexibility would also defeat the purpose, partially.

Imagine having 8 file edits, but when you do a quick search on them in your file system you only spot 7, because one of them had the commentlines disabled. It breaks the consistancy completely, and in this case I find consistancy more important.

Whatever. Why won't it be possible to provide a choice to have edits without the tags? There will definitely be reasons for having edits without them. e. g. many small edits, inline SQL-Edits (and I disagree with you about that point) many small Template-edits among others. A bit more flexibilty would be nice IMHO.
Not to mention code that is in a PHP file but isn't even PHP, which makes those comments display on the page when they shouldn't.