Add Show Version

[tsawyer]

Add a rpt show version to the Asterisk CLI which would include the string from rpt cmd node# status 3 xxx and the git commit hash.

[InterLinked1]

I'll leave this open for now but I think this would need further discussion; modules and subsystems are no longer versioned independently like they used to be when app_rpt was originally written, so I'm not really sure what this would look like. Only a few remaining things still have version numbers like the AMI version number. In release versions, there wouldn't even be a Git commit hash available, just an Asterisk version number. So if this is being upstreamed that needs to be taken into account - would the Asterisk version number suffice on its own?

[tsawyer]

When working on an issue one of the first things we need to know is if the running code is current source. The only way to know that for sure, as far as I know, is to imbed the Git commit hash or a version somewhere it's accessible on the Asterisk CLI.

I think there will be builds of app_rpt independent of Asterisk. So no, the Asterisk version would not suffice in my opinion.

Also I would not think we'd do away with status 3 if that what is under consideration here.

[InterLinked1]

Embedding the Git commit hash will be problematic, since there is no guarantee the user is installing from Git. For example, I don't on my test system for compiling, I just copy the source files over. I think the only foolproof way would be to embed a version number in one of the header files, and ensure it's updated regularly. Technically, this could drift if files are copied over piecemeal as I do, but I think for most users that are using git or some other mechanism to be on a single version at once, that shouldn't pose an issue.

[tsawyer]

How about updating the status 3 message in some way that we can reliably tell what we're running? Maybe a build number or something? The text for status 3 it at the very top of app_rpt/app_rpt.h.

define VERSION_MAJOR 3

define VERSION_MINOR 0

define VERSION_PATCH 0

[encbar5]

Of course if the users are installing from debian packages, you can just query the package manager for the version.

[InterLinked1]

Of course if the users are installing from debian packages, you can just query the package manager for the version.

This is mainly relevant to those who are not installing from packages, for frequent testing, i.e. getting source from Git and compiling from source.

[encbar5]

Embedding an identifier only truly works if the software is being pre-built right? Because if the user is building from source there's always the possibility they modified the files without changing the identifier. It's perhaps an easy help, but can't really be trusted. The only thing that would really prove sameness of the source code would be some sort of signature or checksum.

[InterLinked1]

Embedding an identifier only truly works if the software is being pre-built right? Because if the user is building from source there's always the possibility they modified the files without changing the identifier. It's perhaps an easy help, but can't really be trusted. The only thing that would really prove sameness of the source code would be some sort of signature or checksum.

I don't disagree with that, it's the same concern I raised in my second comment here. The scenarios that would benefit most from this are those least conducive to it.

[encbar5]

I would also point out that it could just be assumed that anyone building from source is a developer or advanced user and manages their own source code and knows how to debug, thus does not need technical support that would require knowing a build identifier. In which case we don't need to worry about this.

[InterLinked1]

I would also point out that it could just be assumed that anyone building from source is a developer or advanced user and manages their own source code and knows how to debug, thus does not need technical support that would require knowing a build identifier.

I'm not 100% sure about this, I think we have several folks building from source, using the rpt_install.sh script and other things that are just "following instructions" but don't actually know much about this.

In which case we don't need to worry about this.

Which is most users right now... in which case I guess this isn't a high priority item at the moment?

[tsawyer]

The reason I brought this up was that I had reported a crash and Danny asked me if I was running the latest. To my knowledge there is no way to determine if the running version is current.

[InterLinked1]

What about the build time in core show settings? Does that help at all?

[tsawyer]

There is a build date for Asterisk but I don't think that tells us anything about app_rpt. Was there something you thought might help?

[InterLinked1]

app_rpt is part of Asterisk... what I don't know off the top of my head is whether that's the last time anything was compiled or not, but if it is, that should indirectly tell us when app_rpt was compiled, at least.

[tsawyer]

I've compiled app_rpt many times since this date: System: Linux/5.10.0-21-amd64 built by root on x86_64 2023-02-22 16:04:14 UTC

[tsawyer]

As we near the first release it would be very helpful to have a version display for support reasons.

Could we please consider rpt show version again?

[tsawyer]

Naveen is adding a new rpt show version command which will close this issue. I'll start a new issue to add that to the ASL3-Menu.

[InterLinked1]

Naveen is adding a new rpt show version command which will close this issue. I'll start a new issue to add that to the ASL3-Menu.

To add onto this, this will output the information in the header file.

Once the official release is cut, afterwards, we'll want to be more cognizant of that and be sure to update the patch number whenever changes are made going forward. It's fine for now, since it's still working towards 3.0.0, but after that, we'll have to manually increment that for future releases.