Breaking Changes

The deprecated method String JavaClass.getPackage() was replaced by JavaPackage JavaClass.getPackage(). To query the package name, please use String JavaClass.getPackageName().
The deprecated method JavaClass.getDirectDependencies() has been removed -> use JavaClass.getDirectDependenciesFromSelf() instead
The deprecated field JavaClass.Functions.SIMPLE_NAME has been removed, please use JavaClass.Functions.GET_SIMPLE_NAME

New Deprecation

ArchUnit does not use contractions anymore within the rules API. So far many methods were phrased like dontHave...() instead of doNotHave...(). In general this seems to be more trouble than worth it and does not read that well without an apostrophe, so all those methods were declared deprecated and have a new counter part without the contraction. A simple search & replace of dont by doNot should fix all those deprecations.
Some methods were deprecated because they were not precise enough, if generics come into play. For example JavaClass JavaField.getType() is not precise enough, because the type of a field is something else than a JavaClass (like T someField or List<? extends T> someField). Thus all those methods have been deprecated to make room for a future extension with generics and instead got a new version explicitly stating that the "raw type" is meant. For example JavaField.getType() -> JavaField.getRawType(), JavaMethod.getParameters() -> JavaMethod.getRawParameterTypes().
Formatters.formatLocation(JavaClass, lineNumber) was deprecated in favor of the newly introduced SourceCodeLocation.of(JavaClass, lineNumber) which will report the correct location (i.e. link for IDEs) via toString()

The default class resolution behavior for classes missing from the import was changed. Before by default missing classes were replaced by stubs, now by default they will be resolved from the classpath. Compare the user guide (see #111)
JavaClass can now be queried for declared throws clauses, any Throwables declared on methods or constructors count as dependencies of a JavaClass (see #126; thanks a lot to @tngwoerleij)
JavaClass can now be queried if it is an array (see #114; thanks a lot to @wengertj)
The resolution of classes from the classpath will now use the context ClassLoader if set (should usually not make any difference, but allows to control the ClassLoader used by ArchUnit for class resolution)
JavaClass now has a more sophisticated JavaPackage attached to it. It is also possible to retrieve any JavaPackage from JavaClasses. JavaPackage offers a more convenient API for dependencies between packages (see #158; thanks a lot to @goetzd for reviewing and user guide adjustment)
For arrays JavaClass.getPackageName() now returns the package of the component type instead of empty. While empty is closer to the Java Reflection API, it is not really useful from a point of view of dependencies. Using an array of a type in a package should cause a dependency to that package (see #161)

The rules API now provides an extensive support for checks of members / methods / fields (see #38; thanks a lot to @hankem for an extensive review and many improvements)

It is now possible to create a CompositeArchRule from several ArchRules to check multiple rules at once (see #78; thanks a lot to @bogsi17)
The PlantUML rules API now understands more types of arrows (description on arrows, arrows from right to left, arrow colors), compare the user guide (see #135)
New predefined rule to avoid the use of org.joda.time in favor of the java.time API (see #145; thanks a lot to @sullis)
The slices API is now more configurable to deal with inconsistent package structures and legacy projects. It is now possible to customize the assignment of JavaClasses to Slices by a simple function JavaClass -> Identifier, compare the user guide (see #156)

Thanks a lot to @alanktwong for improving the CONTRIBUTING docs on how to build the project
Thanks a lot to @wengertj for removing use of deprecated Gradle API
Thanks a lot to @olleolleolle for replacing the PNG build badge by SVG
Thanks a lot to @sullis for updating the Travis build to use OpenJDK 11