Automatic software version numbering for development team

[billko]

Of course, all this stuff falls apart if the dev forgets to update the build spec!

[Bob_Schor]

---

@billko wrote:

Of course, all this stuff falls apart if the dev forgets to update the build spec!

---

I agree 100%.  That's why one suggestion would be to force the Build Spec to be updated, either by checking the "auto-increment" feature on the Version Number or programmatically updating the Version Number from, say, the VCS Revision Number (which would be much simpler and "intuitive" if NI would change the behavior of the "Pre-Build Action" to allow the Action to alter the current Version Number (discussed here -- the present behavior of the Pre-Build Action can only affect the Version Number the next time a Build is done, so you have to "build twice", a foolish system IMHO).

Bob Schor

[billko]

---

@Bob_Schor wrote:

---

@billko wrote:

Of course, all this stuff falls apart if the dev forgets to update the build spec!

---

I agree 100%.  That's why one suggestion would be to force the Build Spec to be updated, either by checking the "auto-increment" feature on the Version Number or programmatically updating the Version Number from, say, the VCS Revision Number (which would be much simpler and "intuitive" if NI would change the behavior of the "Pre-Build Action" to allow the Action to alter the current Version Number (discussed here -- the present behavior of the Pre-Build Action can only affect the Version Number the next time a Build is done, so you have to "build twice", a foolish system IMHO).

Bob Schor

---

It's a shame the pre-build action has "issues".

[James_W]

---

@Bob_Schor wrote:

@A couple of comments on @James_W post:

• I cannot find "Get Application Info".  The "Get Build Specification Version" function has already been mentioned here.  This function requires a Build Specification in a LabVIEW Project.  I've used it in Executables, but I don't recall whether or not I've tried using in in Development Mode.
• A key specification of the Original Poster is that the returned Version would auto-increment (or otherwise automatically change) as code was submitted.  Several suggestions linked extracting Revision information from the VCS during the Commit/CheckIn step, thereby linking the reported Version Number with the Revision number in the Code Repository.
• Perhaps I didn't understand what you were suggesting (particularly as I don't know what function you were suggesting).  Perhaps a tiny code snippet?
• If, in the Development Environment, the return value is that of LabVIEW.exe, how is this helpful to the problem at hand?

Bob Schor

---

Sorry.

I was going from memory. I was referring to the VI  vi.lib\Platform\fileVersionInfo.llb\FileVersionInfo.vi

(a very useful tool)

[Hooovahh]

---

@billko wrote:

---

@Bob_Schor

---

It's a shame the pre-build action has "issues".

---

Yes it is all the more reason for people to vote for it.  Still my process is good enough.  On a build I have a prebuild dialog that shows what the current version is allowing me to change it.  It will show the Major.Minor.Bugfix.Build where the build number is pulled in from the SVN last commit plus one (since I'm expected to commit after the build).  Then I click Okay, the build is forced to fail, and then I build again now with the right information.  Now if I find an EXE on a computer I can go to the about screen where the version is shown (from the vi.lib mentioned earlier) or navigating to the EXE and going to the properties window.  This shows the build version which links to the SVN commit.

[Bob_Schor]

---

@James_W wrote:

---

@Bob_SchorI was going from memory. I was referring to the VI  vi.lib\Platform\fileVersionInfo.llb\FileVersionInfo.vi

(a very useful tool)

---

I found GetFileVersionInfo.vi, which I assume is what you meant.  However, I have no idea how to use it (I tried putting in a string pointing to an Executable, but nothing was returned).  Could not find documentation.  I'm assuming this interrogates some of the information Microsoft saves when it builds executables, but what do you do when in Development mode?  Useful Tools benefit from Easy of Use (or Available Documentation).

Bob "Very Picky" Schor

[James_W]

---

@Bob_Schor wrote:

---

@James_W wrote:

---

@Bob_SchorI was going from memory. I was referring to the VI  vi.lib\Platform\fileVersionInfo.llb\FileVersionInfo.vi

(a very useful tool)

---

I found GetFileVersionInfo.vi, which I assume is what you meant.  However, I have no idea how to use it (I tried putting in a string pointing to an Executable, but nothing was returned).  Could not find documentation.  I'm assuming this interrogates some of the information Microsoft saves when it builds executables, but what do you do when in Development mode?  Useful Tools benefit from Easy of Use (or Available Documentation).

Bob "Very Picky" Schor

---

Nope Bob,

the top level VI in the LLB is "FileVersionInfo.vi" it gets all the file version info and returns it as a very useful cluster (with internal documentation on the VI) - at least in LV 2016 and before! I did make sure I checked the path before I posted as I know how 'very picky' some people can be on this forum (and all the file names in that llb are sooo similar).

I'm sure the SubVIs can be tweaked to point at what you want though.

In Dev mode.

I know that:

1) the APP kind propertynode is not equal to "RunTime System"

or

2) RUN_TIME_ENGINE==False (conditional Disable)

and from either of these I can therefore determine to populate the dialogs accordingly.

James