Hack Properties: Min / Max vB Version
 

The questions like "does this 3.6.0 hack work with 3.6.1" are never going to end, unless... you guys implement a minimum / maximum vbulletin version properties. :) What you say?

Isn't it easier to just update a hack's version? I don't do it as soon as vB release a version, but if I've visited a thread to read the question it takes 10 seconds to do it while I'm there.

No, because the question will then change in the following way:
"Does this 3.6.1 hack work with 3.6.0?"

The problem is that an author will fill out the info when he releases the modification, and at that time he does not know yet until which version it will work.

Nothing is stopping an author to add a text "This will only work until x.x.x" if he wants.

Yes he does, at least if he releases the hack using the latest version of vBulletin available. (and why would he do otherwise?).

But he does not know when the next vB version will be released, what it will be named/numbered or if his modification will still work on that future version.

Why would someone be concerned about a future version that has not yet come out? When it comes out, the author can update the hack properties.

If the author wanted to do that, he could already edit the description and place a line saying "This will only work until version x.x.x".

Since i don't see anyone doing that, i am assuming that it wouldn't be updated if there was a special field or it either. And if there is a field for it, but it is let empty by the author, then a reader would asume that it is still working for the latest released version.

Coders do not do that (or at least I do not do that) because I believe that users do not bother reading through the long introductory posts. They obviously do look at hack properties though since their questions are based on that.

It is not necessary to allow to leave the field blank.

It's also possible that a modification would work for 3.6.0, 3.6.1, 3.6.4... but it doesn't work for 3.6.2 and 3.6.3. So this wouldn't really work well in that situation. In any case, people will always ask questions that are easily answered by reading the first post; or even reading the title of the thread. I like the idea, but it wouldn't fix every related problem.

I would love a system where you click on the vb version field and it displays a page of all the vb versions for a mod - and the status for each version (i.e. Does not Work, Assumed to Work, Tested as Working). When a new (higher) vb version comes out, it would be marked as "Assumed to Work" until the author edits the properties and marks it as "Tested as Working" (or "Does not Work").

you may forget few options or tired to select too many options when posting mod :D ^^

I'll second that one.

Anthony's initial idea is, IMO, a mighty fine one. This expansion of it is even finer. :)

It could even be as simple as a 'Multiple-Selection Dropdown Menu' containing all possible versions of vB for the Forum (3.0.x, 3.5.x, 3.6.x) that the thread is being posted in.

As Anthony says, what possible reason could someone logically have to select a version that hasn't been released yet? It's not like people would believe it, and it would mark that person as either a loon or a liar... how could they have tested it on a version that isn't available?

Going by the logic presented by Marco against the idea, theres no need for ANY of the selection boxes we currently have, as the author could just edit the hack description and add "Supported", "is in Beta stage" etc.

Oh that sounds delicious...:D

Can you give me one example of such modification?

Nice idea. :)

Great! So please do it. :) Thanks.

I can't think of one. I guess I just used a worst-case scenerio. Haha. In any case, there will come a time where it won't work. Will it happen frequently? No.

Not really true. Those options are set when the author publish/update the modification.

The discussion is if the author will return to all his hack threads after a new release is published to change it to state a new highest support version. I doubt many authors will do that following the logic that if they wanted they could alsready do so now in the text.

Please understand me correct. I am not against the idea behind the proposal, it sounds very usefull to me, but i am doubting if it will work in reality.

If they do not go back, they'll have to answer questions. But information in hack properties, as opposed to information in the post itself, is more visible to visitors. Isn't it?

-- just thinking out loud here --

Are you telling me that you will now support all versions within 1 thread because you are essentially telling me that you would when you add "this mod works in 3.6.4, 3,6, 3.5, 3.07, etc"? It's an assumption that most people would come up with.

If that's the case than I will expect you to support questions for that version within the same thread ... and, if you do - don't you think it will be kind of confusing for members?

Here's some of the comments you will receive:
- Is this fix for 3.5 or 3.6.4?
- Hey, I tried that fix but it's giving me errors on my 3.6.1. No, it's for 3.0.7 :D

how about members helping others ... etc, etc

the only way this option would be of any use is if replies could be filtered by versions

-- // just thinking out loud here --

I think they were referring to each series. You'd have a range of 3.0.0 to 3.0.x, a range of 3.5.0 to 3.5.x, and a range of 3.6.0 to 3.6.x. You'd still have to release each modification in each series though.

Maybe I'm wrong, but that's how I understood it.

That's correct.

the same still applies ... I just used the versions as examples.

Not if I don't click the Supported checkbox, no. :)

But, if I did, I would expect to be asked questions about any of the Versions.

I would probably do my best to make the Versions of my Mod as similar as possible, to reduce or eliminate the amount of possible confusion.

A possible workaround to that 'issue' would to be allow thread Replies/Questions to be 'tagged' with the Version number as well.