Jump to content

Recommended Posts

I admit I haven't been having a good morning, so sorry if I've been in an arguing mood.  Not trying to be fan-boyish for Windows, just saying the tools that already exist for doing things in a semi-standard way, are the ones I will prefer to use.  

 

EXE versioning (in my opinion) should live with the EXE.  It is convenient to store build numbers in this EXE as well.

SCC should always (in my opinion) be used.  It is convenient to have the build number in an EXE link to the SCC commit version.

 

Times when EXEs aren't made, or when SCC isn't possible, then other options have to be used to track build information to the source it came from.

Link to comment

I admit I haven't been having a good morning, so sorry if I've been in an arguing mood.  Not trying to be fan-boyish for Windows, just saying the tools that already exist for doing things in a semi-standard way, are the ones I will prefer to use.  

 

EXE versioning (in my opinion) should live with the EXE.  It is convenient to store build numbers in this EXE as well.

SCC should always (in my opinion) be used.  It is convenient to have the build number in an EXE link to the SCC commit version.

 

Times when EXEs aren't made, or when SCC isn't possible, then other options have to be used to track build information to the source it came from.

 

You've nothing to apologise for. Linux fan-boys are 10x worse than Mac fan-bloys 100x worse than Windows fan-boys :D , of which I am one (well, I was until I looked at Windows 10). I think we would all jump to the fileversioninfo library if it worked on Linux and Mac too (which isn't impossible, by the way).

 

The point I'm making is that it is only a a semi-standard way on windows and when you factor in other OSs it isn't standard at all Most x-platform libs, for example, have a function to retrieve version info so the BD constant is arguably the standard.

 

Lets get this in perspective, though. No one is saying never version control or even never link your source version to your executable version. Only that writing complex build tools that are purely for documentation purposes and work on only one of a number of OSs isn't a high priority to x-platform developers. Nice to have but meh.

Edited by ShaunR
Link to comment

Good point, Shaun.

 

In fact, SingleBoard-RIOs made me think about generating a readme file, so that I could easily find out about the version of the application when connecting only via FTP.

All my distributions have a licence, changelog and a readme (and/or HTML help). For remote systems they usually also have a method in the TCPIP interface where you can query the version (which is just TCPIP forwarding of a BD constant or, more commonly nowadays, read and send the changelog) so the client end knows without special connections or tools.

Edited by ShaunR
Link to comment
  • 6 months later...

I'm using git, and because of its decentralized nature, there is no one incrementing commit number that I could put into the "build number" field.

 

It occurs to me that git describe sort of does that, returning the distance from the first tagged ancestor. So for my work as single developer, and with enough discipline giving tags in semver format, something like that should do for me:

 

post-28229-0-35450800-1453032791.png

 

The nuisance is perhaps in the per-machine gymnastics I have to do on windows, depending on which flavor of git is installed/bundled, and whether git is made known to the shell or not (I've seen git-bundle installers which offer not to, in order not to create command conflicts). In my snippet I already figured ways for git-gui, not yet for SourceTree.

Link to comment

Most cross platform dynamic libraries have a libversion function call and there is bound to be one for Git.

 

Not the point (IIUC?). I'm not interested in the local version of git installed, I'm creating a semver of my code (not of the git package) to be perused by my pre- and post-build actions, like creating VIs supplying the version label, albeit fragile, versioning the build, renaming installer packages, etc., from my commit graph.

Edited by ensegre
Link to comment

Not the point (IIUC?). I'm not interested in the local version of git installed, I'm creating a semver of my code (not of the git package) to be perused by my pre- and post-build actions, like creating VIs supplying the version label, albeit fragile, versioning the build, renaming installer packages, etc., from my commit graph.

IC. It was this I was referring to

In my snippet I already figured ways for git-gui, not yet for SourceTree.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.