[Home]

Summary:ASTERISK-07956: Asterisk doesn't have any way to tell the dialplan what version it is
Reporter:xrobau (xrobau)Labels:
Date Opened:2006-10-18 22:24:21Date Closed:2006-10-19 17:10:31
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Core/Configuration
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:With the ENUM (and various other) changes in 1.4, it's pretty much impossible for us (freePBX) to have a 'test' for which version of Asterisk the user is running and branch the dialplan based on that. At the moment we're going to have to have two different engines for asterisk 1.4 and 1.2, which is going to cause us maintanance hassles, which we'd like to avoid if possible 8)

****** ADDITIONAL INFORMATION ******

EG:

exten => s,1,GotoIf(["${ASTERISKVERSION:0:3}"="SVN"])?ast14)
exten => s,1,GotoIf([${ASTERISKVERSION}>1400]?ast14:ast12)
exten => s,n(ast12),..Enum for 1.2
exten => s,n,...
exten => s,n,Goto(fin)
exten => s,n(ast14),..Enum for 1.4
exten => s,n,...
exten => s,n(Fin),NoOp(Leaving Enumlookup subroutine)

Comments:By: Jason Parker (jparker) 2006-10-19 11:55:41

It would probably be relatively straight-forward to add a VERSION() function, that would return the same text as "show version".  The only tricky part there (from a "user" {freepbx in this case} standpoint), is that if it were an svn revision (ie; trunk), it would return that, and it would have to be parsed.
By: Steve Murphy (murf) 2006-10-19 12:43:39

Personally, I favor the global variable route. No change to any interface, no change to the functions list or app lists. It's just there. I see that there's also available from the build stuff, the macros BUILD_{USER,HOSTNAME,MACHINE,OS,DATE,KERNEL} and the global vars ast_build_{user,hostname,machine,os,date,kernel} that correspond, that are available in the asterisk source. There is also an ASTERISK_VERSION_NUM macro, that is available to the source, but it appears to be set to 999999's in trunk.
By: jmls (jmls) 2006-10-19 14:33:42

I would second the global variable route
By: Steve Murphy (murf) 2006-10-19 14:48:25

Nothing like a little IRC chatting to help firm up ideas and come to concensus...!

I quote:

<murf> Qwell-- the ASTERISK_VERSION thing-- what do you think could be done in 1.2, 1.4: add VERSION() function, or global vars ASTERISK_VERSION, or neither, or both?

<Qwell[]> murf: personally, I like the function route


<murf> Qwell-- do you see sliding the function into 1.2 and 1.4?

<Qwell[]> murf: not really

<murf> Qwell-- is it even a possibility that just the vars could be slipped into 1.2 and 1.4?

<Qwell[]> murf: technically it's a feature

<jmls> Qwell[]: i would classify it as a bug. Any app should have the version number available, it's *missing* from 1.2 and 1.4 :)

<murf> Qwell, jmls: I tend to agree with you both.

<Qwell[]> apps can get the version number
<Qwell[]> What you can't do, is get it from the dialplan (easily)

<murf> Qwell, jmls: The vars would have less impact on the 'interface'... that's their only advantage.

<murf> Qwell, jmls: just thought of something. You can use the changes in interface to decide what version of asterisk the dialplan is executing from. For instance, if you try to use a function that's not in 1.2, you know it's 1.0.x or previous. If it is there, you can try a func that's only in the 1.4/trunk... and we can add VERSION() to the funcs in trunk, so you'll know you're in a trunk (1.6) dialplan.

<jmls> murf: mindreader
<jmls> I still think that a version variable would be prefable

<murf> jmls: only trouble is, EVEN if we slip it into 1.2, and 1.4, and trunk, there's all those un-updated versions running out there, that won't have them. It's useless to even try.

<Qwell[]> murf: I completely agree with that
<Qwell[]> if everybody upgraded...heck, you wouldn't need this feature
<murf> Qwell[]: well, if everybody upgraded to the latest rev of their branch, at least, then the vars/func would be a nice trick, but...

<jmls> murf: hmm. I understand the logic, but I still feel it's the right thing to do . *if* ${VERSION} is not set, then it *must* be 1.2.xx or earlier, otherwise we know the version

<Qwell[]> jmls: OR 1.4 beta3
<Qwell[]> So it still doesn't solve the problem

<jmls> arrgh. yeah, I tend to discount betas

<Qwell[]> OR trunk from yesterday

<jmls> jeez. ok, ok, I surrender. Still think it's a good idea ;)

<Qwell[]> I agree.  It *is* a good idea
<Qwell[]> but...

* jmls ducks and runs shouting ${VERSION}

<Qwell[]> it's not something that makes sense to put elsewhere
<Qwell[]> of course, that's just my opinion

<jmls> and I'm just a poor user ..

<murf> jmls, Qwell[]: In a few years, 1.6 will seem a distant, old, antiquated, useless version, and all the newer revs will have VERSION() in them, and you'll be able to tell things apart more easily.

<Qwell[]> murf: absolutely
<jmls> lol
<Qwell[]> murf: and it makes perfect sense to put into trunk

<jmls> people still use nt 3.51
<jmls> Qwell[]: at last we agree  '<

<murf> jmls: I said "more easily"! ;^)-- you'll still have to use the func tests if VERSION() comes up empty.

<Qwell[]> Why do you care about the version in the dialplan anyhow?  Can you give an example of how it would be used?

<jmls> *I'm* always on the bleeding edge. So I know my version, just check the amount of blood to see how close to the edge I am :)

<murf> Qwell: to know which apps/funcs you can use, to know what features you can excersize.
<jmls> Qwell[]: I think some freepbx guys want to know so that they can route things around  in the dialplan

<Qwell[]> fair enough

<blitz[dallas]> Qwell[]: I could see that being useful if you have a cluster with different versions of Asterisk running...

<murf> Qwell, jmls: It's magic: one dialplan that can be used in 1.2, 1.4, trunk, etc. From a distro standpoint, less work, confusion.

<jmls> murf: I am a believer. Follow the gourd.
By: Steve Murphy (murf) 2006-10-19 15:04:29

So, the VERSION func will available in trunk in a few hours... which, really, will be of limited use to you. So, to tell the version, here's an algorithm for you:

a. See if VERSION() returns anything. If so, the version is trunk (pre-1.6) at the moment, or higher. You should be able to use the SVN version to tell reliably which. (because in a year, trunk will be a proto 1.8, right?)

b. If not... See if the RAND() func returns a value (there are a bunch of
   post-1.2 functions available.. if it is, then this is 1.4 release.

c. If not... this is 1.2 or earlier. You might use some other test to see if
      it is 1.2 vs. 1.0, but I leave it to the reader to probe the mysteries of
      ancient history, mythology, etc. for a good reliable test.
By: Steve Murphy (murf) 2006-10-19 17:09:45

I added the new function VERSION to the trunk. see r. 45724.
This should help tell trunk from 1.4 Asterisks. Truly, in the future,
the rev number may be the most reliable method of determining the
true version for trunk revs.
By: Steve Murphy (murf) 2006-10-19 17:10:31

Not much more I can do!