Semantic Version Reporting Tool - Case #1

Currently in master when the report is printed I see this (among many others):

* com.liferay.portal.kernel.dao.search               MINOR      6.2.0      6.2.0      6.3.0      VERSION INCREASE REQUIRED
	<   class      com.liferay.portal.kernel.dao.search.DisplayTerms
		+   method     isSearch()
			+   return     boolean

Notice the leading * in the first line (signifies dirty package state), the suggested version 6.3.0, the warning VERSION INCREASE REQUIRED, the class name DisplayTerms.

What has happened here?

It seems that someone added a new method to the class DisplayTerms. 
The method name is isSearch.

Due to the fact that this is a concrete class, and not an interface, adding a new method is a backward compatible change since it does not break existing code. 

However, it is an API change which needs proper semantic versioning to be applied.

How do we solve this?

Simple! 

Enter the folder which contains the class:
<portal_src_root>/portal-service/src/com/liferay/portal/kernel/dao/search

add the text file:
<portal_src_root>/portal-service/src/com/liferay/portal/kernel/dao/search/packageinfo

contents:

version 6.3.0

Re-run ant all.

Now the report should produce:

  com.liferay.portal.kernel.dao.search               MINOR      6.3.0      6.2.0      6.3.0      -         
	<   class      com.liferay.portal.kernel.dao.search.DisplayTerms
		+   method     isSearch()
			+   return     boolean
	-   version    6.2.0
	+   version    6.3.0

Notice there is no more leading *, the suggested version matches the current version, the warning is gone (replaced by -). 

You should also notice that below the class change, the version change on the package is represented as removing version 6.2.0 and adding version 6.3.0:

	-   version    6.2.0
	+   version    6.3.0

Nice! The package is no longer dirty.

If we had not resolved it properly the report would continue to indicate an issue for the package.

Silencing resolved semantic version reports

Once you get used to resolving issues, you may want the report to focus only on the dirty packages that come up while developing. 
To accomplish that there is another build property which you can set in your build.${user.name}.properties.

 baseline.jar.report.only.dirty.packages=true

This is more than likely what you want if you are a developer.