I setted AssemblyVersion attribute to this:
[assembly: AssemblyVersion("1.0.0.*")]
It is increasing according to change of assembly and time. Now it is: {1.0.0.20042} and if I don't change cs files inside assembly it doesn't increase. But if I change the one of class file in this assembly, version isn't increasing just one. If I didn't misunderstand the articles it is increasing depend on time. But I want to set this increament depend on build number.
Is there any way to learn build number from this version number or to set it's increament 1 ?
I use Auto Version Increment for Visual Studio. It's free and works for VS2005/08 and has a separate version for VS2010.
You can select all sorts of policies on build incrementing, including per-build increment and time based build numbers.
If you've got multiple projects and want to keep the version numbers the same, you can create a shared AssemblyInfo.cs between all projects, then increment the build version in that.
Related
I have the git commits and the tags as below
The tag of the latest commit is 12.0.0-beta.6. When I run GitVersion, the result is as below
So the build number on TeamCity should be 12.0.0-beta.6, but I don't know why the GitVersion generates build number 12.0.0-beta.6+8 on TeamCity.
My build steps are as below
Does anyone know why GitVersion generates the redundant "+8" after the FullSemVer?
How to remove this dedundant "+8"?
Thank you very much.
The +8 is metadata and not actually part of the version number. In the documentation for the version variables, BuildMetaData is described as:
The build metadata, usually representing number of commits since the VersionSourceSha.
You can see the same value 8 exposed as CommitsSinceVersionSouce and this should increase with every commit made to the branch since its "version source", which in this case is the tag 12.0.0-beta.6 made on commit 549a1d.
The metadata does not increase with every build, but with every commit. I can see how the current language is confusing and the name BuildMetaData does not help. Since BuildMetaData is an exposed variable, we can't change its name, but I've submitted a PR that will hopefully clarify its documentation.
Read carefully and understand at least part of GitVerson docs (paragraphs 1+2)
The shortest possible extraction
GitVersion will increment the metadata for each build so you can tell
builds apart. For example, 1.0.0+5 followed by 1.0.0+6. It is important
to note that build metadata is not part of the semantic version; it is
just metadata!
I have recently seen a behaviour which made me ask this on SO . I was hoping that people would be able to share their findings too.
Would a class file (bytecode) be different if the same file is compiled (unchanged) using JDK 1.8 u66 and JDK 1.8 u121? What I mean is the following:
1) I compile an application using JDK 1.8 u66
2) I make changes to 1 or 2 files and recompile using JDK 1.8 u66.
Could I expect some of the unchanged class files to have different binary content even though they haven't changed?
My reason is that when I took a hash of a file which wasn't changed as part of my steps above - they had same size on disk, but the hashcode was totally different. and I used Winmerge to compare these two versions where the size was reported as identical, but the binary contents were different. The following is what I have compared using Winmerge (blue marked item was something related to my source name so I had to mask it out) - but please observe the difference in 208 and 248.
Is this expected? if so, could someone please point me to that literature which explains this?
Regards,
Countless reasons exist, why the same Java source file may be compiled to different bytes by different compilers, where different versions of the same compiler should indeed be seen as different compilers. Even for the exact same compiler there is no guarantee that bytes are identical.
One such reason is, that all references in the code (other than opcodes and bytecode offsets) are indirected through the Constant Pool. The order of entries in the constant pool is not specified and hence it may change leading to all references using a different offset.
See also that JVMS has a section titled Compiling for the Java Virtual Machine, which, however, starts by saying:
The numbered sections in this chapter are not normative
As a result, reasoning works only in one direction: same bytes implies same source code, but different bytes doesn't necessarily imply different source code.
JDK-8067422, as linked from one comment, gives an example where even the same compiler can produce different bytes for the same source file (perhaps due to different set of source files compiled in the same compiler invocation). As per JLS and JVMS this is legal, just inconvenient.
SonarQube Metrics graphs are not being displayed on my project dashboards behind the total numbers and Quality Gate ratings.
Current versions of SonarQube and plugins and MySQL 5.7. I am creating a new SQ project through its Administration->Projects->Management->Create Project and then performing analyses as follows (anything capitalized is either a variable or anonymized): *
MSBuild.SonarQube.Runner.exe begin /k:KEY /v:VERSION /d:sonar.host.url=http://localhost:9000/ /d:sonar.login=TOKEN /d:sonar.projectDate=YYYY-MM-DDTHH:MM:SS+0000
MSBuild.exe /maxcpucount /nr:false /nologo /target:rebuild /verbosity:quiet PROJECT\PROJECT.sln
MSBuild.SonarQube.Runner.exe end /d:sonar.login=TOKEN
I have tried VERSION equal to a constant value "1.0" and VERSION equal to a string of the UNIX time (seconds since 1/1/1970) of each git commit I analyze. I've also tried configuring project leak periods of the last 90 days and also previous_analysis, though I think that would only affect the graphs in the right column. If someone could tell me what I am doing incorrectly, I would appreciate it.
* These are examples of the commands executed by a Python script that is iterating over a list of git commit hashes and their associated timestamps, in increasing order, to populate the project history. The python script in turn is mimicking a Jenkins job that will eventually take over calling SonarQube.
Background Tasks page:
Your project homepage screenshot shows the graph in the leak period, but not extending left into the Overall section.
This is going to be a question of your analysis date and your definition of "leak period". If your leak period is set to previous_version, then you need to take a look at the sonar.version values in your analyses. So far, it looks like all your analyses are leak period analyses, which is why nothing has filtered left into the overall view.
I have a build-server, implemented with team-city.
Until now, I have an input parameter that represent the first 3 parts of the version number (x.y.z) = %Version.Number%
When I compile my exe files, I set the file version to be:
%Version.Number%.%build_number% and then I get a 4 parts version number.
The problem with that solution is that there is no connection between the first 3 parts of the version number and the build number.
Now, I want to find a way to have a different set of %build_number% for each %Version.Number%.
I will illustrate the problem with an example:
On the first build when %Version.Number% = 15.3.2 - the version number will be 15.3.2.0 .
On the second build when %Version.Number% = 15.3.2 - the version number will be 15.3.2.1 .
Now, on a new build when %Version.Number% = 16.0.0 - the version number will be 16.0.0.2
and I want to be 16.0.0.0.
Thanks.
Two ways to handle this, at least:
Use the Version Number Plugin -
it will allow you to reset the "running" build number whenever you like -
simply set the next-build-number to '1' whenever the major release is increased
(as a bonus, it also lets you format the version-number with leading-zeroes and such).
Create a new job whenever you increase the major release number -
copy build_job_15.3.2 to build_job_16.0.0
edit the version-number in build_job_16.0.0 to be '16.0.0'
optional: disable build_job_15.3.2
Now you can run build_job_16.0.0, and the build number will start with '1'
(this method is a bit tedious, but allows you to continue building 15.3.2 releases, if needed).
You are able to reset the build number counter in the General Settings of the Build Configuration. Is that not sufficient for your scenario?
What are the rules for the build numbers Visual Studio generates when a project build number is x.x.* or x.x.x.*? I don't know where the documentation for this is and Google didn't yield what I was looking for...
The rules have been documented for a long time, under the AssemblyVersionAttribute:
You can specify all the values or you can accept the default build number, revision number, or both by using an asterisk (*). For example, [assembly:AssemblyVersion("2.3.25.1")] indicates 2 as the major version, 3 as the minor version, 25 as the build number, and 1 as the revision number. A version number such as [assembly:AssemblyVersion("1.2.*")] specifies 1 as the major version, 2 as the minor version, and accepts the default build and revision numbers. A version number such as [assembly:AssemblyVersion("1.2.15.*")] specifies 1 as the major version, 2 as the minor version, 15 as the build number, and accepts the default revision number. The default build number increments daily. The default revision number is random.