OSGi Community Event 2014
Abstract:
Most people consider versions tedious and boring. And they are right! However, that does not make them less important. Unless you always compile all your code together and never have to go back in time, versions are the threads that keep the systems together in a stable way. That is, if people did not make those stupid mistakes with versions ...
Meet semantic versioning and baselining. Semantic versions provide a framework to automate version handling. This framework is used in bnd(tools) to automate most version handling.
This presentation will show what OSGi semantic versions are and its extension to also semantically version contracts. It will demonstrate the bnd(tools) support which is part of enRoute to detect semantic version violations in real time as well as in the continuous build.
Speaker Bio:
Peter Kriens is an independent consultant since 1990.He currently works for the OSGi Alliance and jpm4j. During the eighties he developed advanced distributed systems for newspapers based on microcomputers based on, at the time very novel, object oriented technologies. For this experience in Objects he was hired by a number of international companies, including Adobe, Intel, Ericsson, IBM, and many others. During his work at Ericsson Research in 1998 he got involved with the OSGi specification; Later he became the primary editor for these specifications. In 2005 he was awarded the OSGi Fellows title. After taking a sabbatical in 2012 to develop jpm4j he returned to the OSGi Alliance to help increasing adoption. He is Dutch but decided to live in France.
15. Binary Compatibility
• Reimplementing existing methods, constructors, and initializers to improve performance.
• Changing methods or constructors to return values on inputs for which they previously either
threw exceptions that normally should not occur or failed by going into an infinite loop or
causing a deadlock.
• Adding new fields, methods, or constructors to an existing class or interface.
• Deleting private fields, methods, or constructors of a class.
• When an entire package is updated, deleting default (package-only) access fields, methods, or
constructors of classes and interfaces in the package.
• Reordering the fields, methods, or constructors in an existing type declaration.
• Moving a method upward in the class hierarchy.
• Reordering the list of direct superinterfaces of a class or interface.
• Inserting new class or interface types in the type hierarchy.
23. • Consumers – Changes to the contract are usually
backward compatible. Only MAJOR changes
require a new implementation.
• Providers – Almost any change to the contract
requires a new implementation. MAJOR and
MINOR changes require a new implementation.
30. “We encourage development systems to
provide facilities that alert developers to the
impact of changes on pre-existing binaries that
cannot be recompiled.”
— Java Language Specification