What are the requirements for the vsn key in an Erlang application?
The Erlang/OTP documentation simply says:
Version number, a string. Defaults to "".
Is there any required ordering between versions? If I use a git SHA, will I still be able to use relups or appups?
To rephrase:
Is there anything in Erlang/OTP that requires a well-defined partial or total ordering in the vsn key?
The version can be any string, but with your idea I see 2 problems:
You will loose the ability to make comparison on version easily, I mean that you will need to maintain a catalog of all existing versions just to know if one version is older than an other (it should be accessible via git)
but as far as git works at the project level, you cannot know the SHA, and as the app file is part of the project, you cannot fill the version before commiting unless the app file is out of the git repository, which is not really interesting.
Related
I am implementing a CI process on TFS. I would like to use semantic versioning and semantic versioning should be incremented automatically. Also, I would like to use descriptors like “CI”, “beta”, and “release”.
It seems GitVersion is a suitable tool for this purpose. But as far as understood, especially descriptors generated according to git branch. We don't use gitflow, we use trunk based development.
versioning nuget package
GitVersion Documentation
While using only one branch. Is it still possible auto incrementing version number and putting proper descriptors such as CI, "release". If it is possible a good blog post or step by step tutorial would be very helpful.
Also, if you know an alternative tool or how to implement such a versioning on TFS. It would be helpful too.
To version control in one branch, we can only check in the changes with meaningful comments.
To increment version number in TFS, you can create a build/release definition. Then set the build/release name format as needed. It's applied to both TFVC and Git.
For the build/release name format, you can use a combination of tokens, variables, and underscore characters to set much more useful names that are meaningful to your team.
eg:
CI_Beta_$(TeamProject)_$(BuildDefinitionName)_$(SourceBranchName)_$(Date:yyyyMMdd)$(Rev:.r)
Just add the Copy File step to save the versioned source to any server or UNC path.
Please see Build definition options for details.
My build system (Team Foundation Server 2015) does the following:
Get latest
Un-shelve developer changes
Check-out version file
Modify version file
Check-in modified version file
Run build/unit test
Check-in developer changes (on successful build/test run)
My issue with this method is that the build agent is modifying a file and checking that change in. To me this feels dirty.
So is there a better way of doing this, is this really best practice?
In my opinion, it's better to put version information in a version control system, not in a file. I haven't worked with TFS, but in my work I use Git and put version information in git tags. Using the git describe command you can get the information about the latest tag, a number of commits since the last tag and hash of the last commit. It also can provide you with information about uncommitted changes in your working copy.
All this information gives you the ability to distinguish one version of a binary from another.
And you don't have to create meaningless commits inside your repository.
I wanted to know how you deal with the versioning of your iOS apps. CFBundleShortVersionString should match with the version submitted to iTunes Connect and CFBundleVersion is your unofficial build number.
For CFBundleShortVersionString often the format {MajorVersion}.{MinorVersion}.{Revision} is used. One could use the {Build} number for the CFBundleVersion. Another possibility would be to use some sort of revision number from the VCS or in my case the SHA1 hash of the commit of GIT.
If you submit an app to the app store the CFBundleVersion is used to determine if your app is an update. It is only allowed to use digits and the dot separator here and it should be higher than the older version. So using a hash doesn't work here and there is no revision number in GIT. Once the app is ready for release the app can use the same value for CFBundleShortVersionString and CFBundleVersion if you have some different naming for the build number which is not compatible with the app store.
Currently the only thing which comes to my mind is to manually enter the version number if the app is ready for release. So you start counting if you have v. 1.0.0 and increases the number if you provide a new release. If you have a new beta version (e.g. you are planning a new release 2.0.0), what do you use for CFBundleVersion? Or what if you use continous integration and a new build is generated each day at midnight?
Also is there an automated process which connects Xamarin Studio, Info.plist and GIT so that for example the build number is increased on each commit? And how does such a process look like?
Bonus question: What information do you show the user in the about dialog of the app?
This is not full answer on how to handle inserting version into Info.plist and iOS versioning but instead how MonoDevelop/XamarinStudio creates version number from GIT commits. Which you can probably use to hack some way to update your Info.plist.
https://github.com/mono/monodevelop/tree/master/scripts
This folder has 3 files .sh and .bat are just to compile third file(.cs) and execute it.
So if you look into this .cs file you will see:
How to get "git.exe"
How to run blame on version.config(this is file where you manually insert versions like(5.5, 5.7, 5.8...)
How to run "rev-list --count " + hash + "..HEAD" which means count all commits between last change to version.config file and current commit. So if version.config was changed 143 commits ago, version will be 5.5.0.143, you can of course still use 3rd place for service packs.
And also some output of this informations like for example buildinfo which can then be used by other parts of build process to insert into Info.plist.
I hope this helps you to solve your problem.
I'd like to have a version indicated for my builders i.e Version:101, that is both in my project and in the comments of my version control (GIT).
This is to ensure that if I ever need to change code deployed in production I can find that codes version number from the project, and match it to the GIT revision, then check it out to modify and re-deploy.
I'm using ASP.NET MVC . does anyone know of a good way to do this? I'd like it DRY I.E I mark the version n.o in the code and then GIT picks it up or something.
How can I do this?
If I understood your question correctly, you want that your binaries have the version number somewhere. I'm assuming you are using annotated tags for versioning. For a C++ project I did something like this:
Create a pre-build script that runs the command git describe (and append --match "v[0-9]*" if you use tags for other purposes too) and spits out a file that you can use in the project. For my project, this was "gitversion.h" that had the following:
#define VERSION "v1.2.3-5-g472ac4f"
This file should be in your .gitignore file, you don't want it to end up in the repository.
Then use that file in your build as usual.
.dproj files are essential for Delphi projects, so they have to be under version control.
These files are controlled by the IDE and also contain some information that is frequently changed, but totally irrelevant for version control.
For example: I change the start parameters of the application frequently (several times a day), but don't want to accidently commit the project file if only the part dealing with the start parameters has changed.
So how to deal with this situation?
A clean solution would be to take the file apart, but that isn't possible with the Delphi IDE AFAIK.
Can you ignore a specific part of a file?
We're using Subversion at the moment, but may migrate to Git soon.
In our case, it's rare for a developer to make a meaningful change to the .bdsproj, .dpr, .res files. So we reject the commit (pre-commit hook in subversion) unless special tags: [add project file] or [add res file] are present in the commit comment. This prevents "frivilous" changes to those files.
SVN/git cannot "know" which bits of the file are important, and translating what is important for you to commit or not into file "bits" would be difficult (especially when you don't know exactly how the information is structured within it). The most practical solution is to check the changes that have been made to the file and decide whether to commit them or not to the repository.
You can decide which bits of the file you want to commit with git. This is not, however, the automated process you seem to be looking for.
For the specific case of startparameters: the DDevExtentions plugin of the well known Andreas Hausladen allow for the start parameters be stored separetely of dproj file. See more details about DDevExtensions on his site.
EDIT: If I remember correctly, this feature was created just because he had that exact problem with start parameters and version control.
I would not save the .dproj files directly in version control, but rather provide a default file which should be renamed by the user to get the flawed Delphi working.
Use the --assume-unchanged option on git update-index <file> as described here and stackoverflow/what-is-assume-unchanged.
You could make simple aliases for the those who need it made simple.