I want differential view based on version , how to assign version to my current set of issues / analysis?
Issues cannot be assigned a version.
Issues are tied to a project & the project has a version. Let's say it's currently 1.0.
When you update the project version to 1.1, you'll then be able to distinguish issues created since previous_version.
To set up the differential, just look at the interface, it will guide you in your options:
Number of days before analysis, for example 5.
A custom date. Format is yyyy-MM-dd, for example 2010-12-25
previous_analysis' to compare to previous analysis
'previous_version' to compare to the previous version in the project history
A version, for example '1.2' or'BASELINE'
Related
How do I get the measures (like code-coverage, technical debt, complexity, nloc, ...) of a certain build version (eg. 1.0.0.20) from the api of SonarQube?
My goal is to get these information and display it along with some-other info pertaining to that version got from other sources like bitbucket.
I am able to only see the measures of the current (latest) build (eg. 1.0.0.45) version through the api/measure/component api link.
Although, I can see these measures for individual builds through the UI under the compare option. But how to get it through rest api?
SonarQube Version 5.5
Plugins:
sonar-scoverage-plugin-5.1.3.jar
sonar-scm-git-plugin-1.2.jar
sonar-scalastyle-plugin-0.0.1-SNAPSHOT.jar
sonar-javascript-plugin-2.11.jar
First of all, SonarQube 5.5 is old, you should first consider using the latest LTS (5.6) in order to be able to get feedbacks.
Versions of projects can be found by using :
api/events/index (it's replaced by api/project_analyses/search in 6.3) -> it will return you the date of analysis on which there's a version.
And in order to get measures from the past, you can use :
api/timemachine/index (it's replaced by api/measures/search_history
in 6.3) -> you'll be able to found the measures from the version you want.
Ours a complex enterprise app and we use one third party library which we would like upgrade.But we do want to maintain two versions atleast for couple of releases till we are good with the newer version and switch which version to use by a configuration property.
We are trying maven shading for the same.
However the problem we are facing is like this. The changes between the two releases are very drastic. For example A is a class in version 1.0 and is now an interface in version 2.0
So let us say for example in the existing client code we say
A a = new A();
This would have to be changed to some other call in the new version.
Are there any ideas on how to make the client code compatible with both the versions?
I don't believe there is a way to write code compatible with both the versions.
Keeping multiple versions of same jar may create maintenance nightmares.
I suggest to create/maintain separate SVN branches for each version of this jar.
You can decide which SVN branch should go into production based on maturity of that branch.
You can simply replace the war from other branch, if any issue during deployment/in production.
At the top of the SonarCube page for my project there is a drop down box to access deltas - but I can only choose "since previous analysis", and "over 30 days". As I have a very slow developing project, like a version every two months, the 30-days choice is of no use for me at all, and this drop down boils down to two versions.
What I need is to compare any two arbitrary versions of the project (that Sonar analysed before). Is this possible? How?
Note: Currently I run SonarQube 4.3.
Like what you can read on the documentation of the differential view feature of SonarQube, you can achieve this using the "period 4" or "period 5" properties at project level, and specify a version to compare to.
Note that you can update the analysis history of your project to add versions on specific analyses, as described on the History and Events documentation page.
I want to make the builds on a specific branch advance the version number in AssemblyInfo.cs files and in Package.nuspec files according to the Semantic Versioning convention (*).
In order to do this, when code is merged into this specific branch, I want to:
Ask the merging user for a new version number, preferably during merge (then run build during check-in) or when the user runs a manual build, preferably displaying a custom dialog which displays current version number and asks if API has been broken, expanded or if changes do not affect API, then save the new version number aside.
Apply version number to AssemblyInfo.cs file(s). (Related link)
Apply version number to Package.nuspec file(s).
Run build.
Publish resulting NuGet packages.
I am not sure how to get the first step working, as it is interactive.
Has anyone tried such as approach before?
Are there any known solutions?
Any tips how to solve this?
(*) Semantic Versioning convention:
MAJOR version when you make incompatible API changes,
MINOR version when you add functionality in a backwards-compatible manner, and
PATCH version when you make backwards-compatible bug fixes.
I am looking forward to implementing a daily build for an upcoming project.
But before doing that, I need to know how to properly version an assembly.
I have the following concerns:
Should each assembly have an independent version number or should they all share the same version?
Should I use a * version for build and revision?
Is revision relevant to daily build?
We stamp all the assemblies within our products with the same version number using the following steps:
Link all assemblies to an
AssemblyInfoCommon.cs containing the
version number info: see here
for an example.
Generate the AssemblyInfoCommon.cs file as part of the build
using (in our case) the NAnt asminfo task, Cruise Control .NET and the SVN revision labeller
In our case, we don't use the * version. All deployed versions are built on the build server. We don't worry about version number on our desktops.
The answer really depends on what you are trying to accomplish with the assembly version numbers. If you are doing a ClickOnce deployment and want to do independent downloads of updated assemblies, you will need to have each assembly independently versioned -- otherwise, I think it's often nice to have assembly versions match the software release number. In more complex scenarios you may need another strategy.
A scheme I used at a prior company was major.minor.revision.build -- so in version 1.0 of the product, the assembly version and assembly file version on each assembly was 1.0.0.1129 (for example). This made it easy to match up what assemblies were part of which software release, down to the build number. We accomplished this using a pre-compilation search and replace in each AssemblyInfo.cs file to replace a token with the version numbers provided by our automated build process.
So Each assembly should have the same version which is typically a combination of the release version ie 3.4 + the build number which is a sequence that represents the number of times that release has been compiled on the build server. The revision is relevant because it demonstrates the number of builds that you have created for that release. You can really do this in one of 2 ways. The first way would be that if you planned a release ie 3.4 then when you start working on that release then that is your major version number and your minor version number increments with the build. Another way to do this is to tightly control the build versions in that when you are ready to perform your release to QA / Regression you set your major version to 3.4 and you leave your minor version number to 0. You keep things tightly controlled this way until you release. This way you can control your service pack numbering through the minor version number. Hope this helps.
I would normally agree that all assemblies should have the same version number; however, I would make one caveat to that. If one of the assemblies is used somewhere else outside of this project or if it is considered it's own project it should have it's own version number. It should also probably be moved out of that solution and into it's own. The only reason I mention this is that I have seen numerous occasions where people have an assembly that's used in a couple of other places, but mainly in one place and they try and keep the version straight. It's a bad idea to do that. I think the Single Responsibility Principle applies at the solution/project level as well.
As far as numbering goes, I agree with Guy Starbuck (major.minor.revision.build). That's the way I've always done it and it has always worked well.
We have a large app (hundreds of assemblies) with frequent releases (about 1 a month). We went for the "give every assembly the same version" but its a constant source of fustration to me that assemblies for 1 version are completely incompatible with those from another, despite the fact that the interfaces of these assmblies rarely (if ever) change.
If this is case for you then you might benefit from versioning assemblies separately - each time you update your assembly only bother to increment the version number in cases where you actually want to break assembly binding (for example if the interface changes, or the changes are otherwise significant enoigh that you want to prevent someone from accidentially using the previous version).