Don't ignore me! (attn: script authors)


Yes, this is a deliberate play on the wording of my other version-checking-related post. ;)For those who don't know, I'm working on an overhaul of sorts to version checking. It will at least be implemented in std_lib.ash, and of course zarqon is welcome to put it in zlib.ash instead if he prefers.I would like some advice / feedback on how to handle a few things before finishing off the main routine, so here's what it does so far

1) Strings are converted into an int [int] map. Anything preceding the first integer is stripped off of the front, so script authors can use "v", "r", "my big phat new version" or whatever. Putting numbers in the descriptive beginning is prohibited though, as that's just a PITA to deal with.

2) The script looks at integers separated by the following delimiters: . (space) : _ - (That's a space in there, can't really type it out though in a readable manner). So the main "numerical" part of your script could be "0:3-44 123456_2.1" if you wanted.

3) The script can also recognize "d[ev|evelopment]", "a[lpha]", "b[eta]", "r[c|elease candidate]" if they immediately follow the "main" numerical part of the version string (spaces between are ok). This, in turn, may be optionally followed by integers (no delimiters here; we go too far and it's delimiters all the way down). So that gives you the possibility of having "v1.2.4d2" as a valid version string, with 1,2,4,d,2 being the compare-ready information.

4) When comparing two version strings, if the main numerical parts have different levels of significance, the shorter is padded with 0's before the pre-release info is looked at. So, "r1.4.2d2" and "v1.4a1" would compare as 1,4,2,d,2 and 1,4,0,a,1 respectively.

5) Pre-release alphabetic parts are converted to numbers; dev is lowest, then alpha, beta, rc follow. If none of these are matched, it's assumed higher than all of those (so that when a script doesn't have such info in its version, it's assumed "more advanced" than, say, a dev version). However, if followed by a number, that will still be used, so you could theoretically make up your own "pre-release" tag; but you can't use more than one. Again, going for sanity here.

6) Two new zlib var's are being added. "version_check_significance" will be an integer for what level of checking should be used. 0 means "any change should trigger an update notice" (and this will be the default, to preserve current behavior); other integers are number of digits from the left. Eg if you have "v1.2" and have "version_check_significance" set to 1, "v1.3" won't alert for updating; "v2.0" will. "version_check_pre_release" will be a boolean, defaulting to false. If script authors add extra information to their post that signifies and additional version of their script is available as a pre-release (unstable, dev, whatever) version, check_version() will look at this version instead of the "stable" version to determine if updates should be made.So, script authors will be able to release versions for testing to the core mafia scripting community without worrying about generating bug reports from those who aren't capable / ready for the various informational digging that helps with debugging.

So, after that wall of text, what is it I want feedback on? Here we go!

1) Should "pre-release" checking be on a per-script basis? This would require an additional (or modified zversions) data-file. I think in general, those of us who are comfortable with pre-releases will want them whenever available, so it seems pointless to configure per-script. Also, that's a lot of "fiddliness" IMO. But if several people say otherwise, I can change my approach.

2) Does anyone have a prefered syntax for pre-release notification? I'm thinking just "Pre-release: [pre-release version]", probably in bold or something, but nothing more complicated.

3) You may notice that I don't mention separate mafia revision number checking for pre-releases. I assume anyone who would opt-in for pre-releases keeps fairly up to date on mafia, and if they see "function undefined" or whatever the message is, they'll know what to do. ;) That part will just be ignored for script posts with a pre-release version that the user has opted to check on, unless you guys think otherwise is worthwhile.

I think that all of this should pretty much cover 99% of all reasonable version-checking scenarios. Note that it even means you can start using ISO dates for versioning, if you want! :pAnyway, please comment / poke holes in my methodology / etc.


Staff member
I'm not ignoring you, but you propose adding a degree of complexity to version checking that does not match at all well with my processes as a low volume script developer or a script user. So I'll adopt/adapt whatever seems to be a community standard.


Fair enough, but that's why I've taken pains to make it so that by default, it works as close as possible to the existing version-checking methods in zlib. As far as I can see thus far, any way of naming a script's version that works under the current check_version() will work under this one as well.

I do admit that allowing people to set their scripts to give notice of updates only on 'major' version changes could be problematic, and would welcome feedback on that issue.


Active member
Yeah... I'm seeing that as causing problems much worse than when zlib verbosity used to keep setting itself to 0 for random newbies, because we WANT to allow them to turn off seeing that there are bug fixes, so it's not something we'll just be able to fix by having it turn itself back on later.

Basically, if it makes it to the forums, it's because the author has decided that the currently existing bugfixes are big enough that they really should go fix them. If for some reason you don't want them, and you're enough of a power user to legitimately be able to judge whether or not you need them, you should be able to manually change your version number in the script file to match the release you're wanting to skip.