getVersion()

[bubblobill]

Is your feature request related to a problem? Please describe. Recently discovered a bug in 1.7 that broke one of my macros. The bug #1874 was promptly fixed, but my macro needs a workaround for that specific release.

Describe the solution you'd like A MapTool free of bugs. A function the returns the MT version so I can incorporate the version into conditional operations. e.g. getVersion() A conditional operator based on version to substitute for if(): e.g. version(<1.7): this; that

Describe alternatives you've considered I could probably dig up the information in getInfo but would rather there were proper functions.

[cwisniew]

json.get(getInfo('client'), 'version') Will already return the version number and is prefered over adding a new function as new function will only work from 1.8 onwards where as this works all the way back to midway through 1.3 :)

[Phergus]

And you can also do /version.

[JamzTheMan]

We have generally put things into the various getInfo jsons that we feel dont require specialized functions and only return static data.

I dont think version info requires it's own macro.

[bubblobill]

json.get(getInfo('client'), 'version') Will already return the version number ...

That would be great, if it was a number. Can someone provide me with a list of all versions then? (not just release)

[cwisniew]

json.get(getInfo('client'), 'version') Will already return the version number ...

That would be great, if it was a number. Can someone provide me with a list of all versions then? (not just release)

Not sure what you are after because any new getVersion() function would return the same value as above, there is no other version information to return (unless you want commit but that is not directly comparable so it wouldn't help you).

The releases and prereleases are the versions, others will just return a version indicating its a development build, excluding forks of course they could be doing their own thing.

[melek]

Perhaps the desire is for an easy way to compare versions, a if(version > 1.7) kind of thing?

[JamzTheMan]

Perhaps the desire is for an easy way to compare versions, a if(version > 1.7) kind of thing?

That would be a different request to be honest then. A semver checker. I use one for my libs, just parsing on . And compare major then minor then patch. Its pretty easy to do with the current code base.

@cwisniew with notebooks, i could see an influx of needing to compare versions, not just maptool but the various pieces.

So you see a need then for a fuction that takes two semver strings and compares them?

[bubblobill]

As mentioned in the original request. Either

Describe the solution you'd like A function the returns the MT version so I can incorporate the version into conditional operations. e.g. getVersion() A conditional operator based on version to substitute for if(): e.g. version(<1.7): this; that

My use case is

[if(getVersion()<1.7), code:{
    workaround for permissions bug
};{
    proper way to do it
}]

[cwisniew]

As mentioned in the original request. Either

Describe the solution you'd like A function the returns the MT version so I can incorporate the version into conditional operations. e.g. getVersion() A conditional operator based on version to substitute for if(): e.g. version(<1.7): this; that

My use case is

[if(getVersion()<1.7), code:{
    workaround for permissions bug
};{
    proper way to do it
}]

What happens if the bug is in 1.8.2 but not in 1.8.3? It's unlikely we would ever have a function to return the version number that is not actually the version number. So you would be left with the same info from getInfo() but it wouldn't work for existing versions only starting in 1.9

[cwisniew]

Perhaps the desire is for an easy way to compare versions, a if(version > 1.7) kind of thing?

That would be a different request to be honest then. A semver checker. I use one for my libs, just parsing on . And compare major then minor then patch. Its pretty easy to do with the current code base.

@cwisniew with notebooks, i could see an influx of needing to compare versions, not just maptool but the various pieces.

So you see a need then for a fuction that takes two semver strings and compares them?

we could do that but with notebooks I am hoping to get MTScript 2 included so we need to start preparing functions for MTScript 2 rather than doing thing the way they are done currently, so it won't be in 1.8.

[bubblobill]

Obviously it would only work for future versions, but that would mean those future versions could accommodate workarounds before fixes are implemented. That's kind of the whole point.

[if(getVersion()<'1.8.3'), code:{
    workaround
};{
    proper way to do it
}]

I'd write a UDF if I could easily get a list of versions to compare to.

Ideally I would prefer a branching operator

[version(<'1.8.3'):
    one thing;
    another thing
]

[cwisniew]

Obviously it would only work for future versions, but that would mean those future versions could accommodate workarounds before fixes are implemented. That's kind of the whole point.

[if(getVersion()<'1.8.3'), code:{
    workaround
};{
    proper way to do it
}]

I'd write a UDF if I could easily get a list of versions to compare to.

We can add a function to compare semantic versions in 1.9 so you could use that to compare getInfo() information to version you are looking for.

As per my previous comment though, if you are looking for a list of versions its the releases (including prereleases) for 1.4 onwards. If you want 1.3 then things get a lot more complicated, but hopefully people are no longer running 1.3...

[bubblobill]

Surprisingly, its the versions before 1.4 I could not compile by hand.

[bubblobill]

I see the semantic version comparison being more useful as that would allow people to check versions on their own and other people's code. That might even be necessary if we go down the road of curated frameworks with some of the modularity people have been proposing.

[JamzTheMan]

@cwisniew I agree, if MTScript2 is on the horizon, we should put a hold on any new functions and their issues unless the fixes are deemed important enough for current framework development.

I say lets put this issue on hold and review again for a later release. This is clearly a "convenience" function as the data is available and a UDF could be easily created to do the same work. (we could post a sample macro here which may be handy for others that search GitHub for similar issue?)

@bubblobill I'm not sure if you just need a static list of releases or want a dynamic list but all our current "releases" via GitHub would be accessible via the GitHub API and could be grabbed using REST methods IF really needed that way. But none of the 1.3 releases would be there, and they have their own 1.3bxx versioning scheme. 1.4.x used the older 4 dot scheme as well so 1.4.0.0 -> 1.4.1.9, and most of those didn't have GH "releases".

Only versions >= 1.5.0 actually use semantic versioning, and really only >= 1.6.0 did we start trying to adhere more to major.minor.patch schema. All the 1.5.x releases were more than "patch" level and include actual new functionality vs just bug fixes. e.g. Macro code that worked in 1.5.12 may not work in 1.5.4 for this reason so comparing against "1.5" may not be enough.

Just food for thought.

[bubblobill]

I only want a static list for everything before semantic versioning. Once the versioning becomes consistent manipulating the string is easy.

[bubblobill]

Expired from old age.