hooovahh Posted July 6, 2015 Report Share Posted July 6, 2015 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. Quote Link to comment
ShaunR Posted July 7, 2015 Report Share Posted July 7, 2015 (edited) 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 , 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 July 7, 2015 by ShaunR Quote Link to comment
ShaunR Posted July 7, 2015 Report Share Posted July 7, 2015 (edited) 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 July 7, 2015 by ShaunR Quote Link to comment
ensegre Posted January 17, 2016 Report Share Posted January 17, 2016 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: 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. Quote Link to comment
ShaunR Posted January 17, 2016 Report Share Posted January 17, 2016 The command line is never a solution on windows. That's a Linux fetish. Look for the DLLs. Most cross platform dynamic libraries have a libversion function call and there is bound to be one for Git. Quote Link to comment
ensegre Posted January 17, 2016 Report Share Posted January 17, 2016 (edited) 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 January 17, 2016 by ensegre Quote Link to comment
ShaunR Posted January 17, 2016 Report Share Posted January 17, 2016 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. Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.