I raised this topic in a recent discussion thread, but would like to have it formally voted on because I think it's pretty important.
The proposal is to adopt semantic versioning [1] for both Isis core and the components. More detail below on this. The vote will be open for 72 hours. [ ] +1 [ ] 0 [ ] -1 ... please explain why ~~~~~ More detail on the proposal: Version numbers are in the form x.y.z : - x is bumped up whenever there a breaking API change - y is bumped up whenever there is a new feature that does not break API - z is bumped up for minor bug fixes. This scheme would be adopted for both core and components. Version numbers would not be kept in sync. Version ranges may not be used (*) For example * core 1.0.0 is released * isis-objectstore-jdo 1.0.0 is released, dependent on core 1.0.0 * isis-viewer-wicket 1.0.0 is released, dependent on core 1.0.0 * core 1.0.1 is released. This is NOT picked up by either of the above components. * isis-objectstore-jdo 1.0.1 is released, dependent on core 1.0.1. This also incorporates a number of its own bug fixes * core 1.1.0 is released, providing a new feature * isis-viewer-wicket 1.1.0 is released, using the new feature provided by core 1.1.0 * isis-viewer-wicket 1.2.0 is released, offering its own new feature. It still depends on core 1.1.0. * isis-objectstore-jdo 1.0.2 is released. This has some bug fixes and depends on core 1.1.0 (even though it does require the new feature introduced in core 1.1.0) * core 2.0.0 is released, making breaking changes to the objectstore API * isis-objectstore-jdo 2.0.0 is released, dependent on core 2.0.0 * isis-objectstore-jdo 2.1.0 is released, providing a new feature. It depends on core 2.0.0. * isis-viewer-wicket 1.2.1 is released. This has some bug fixes, and also updates to run against core 2.0.0 At the end of this sequence we have: - core 2.0.0 - isis-objectstore-jdo 2.1.0, dependent upon core 2.0.0 - isis-wicket-viewer 1.2.1, dependent upon core 2.0.0 To avoid "jar hell" (components having conflicting dependencies of core) our recommendation to end-users would be to configure the maven-enforcer-plugin and its DependencyConvergence rule (good practice for all maven projects) [2] (*) with semantic versioning it might make sense to allow for version ranges for the "z" and perhaps "y" components. HOWEVER, I recall that one of the plugins we use for release - can't remember which one just now - has a bug meaning that we cannot do this even if we wanted to. [1] http://semver.org. [2] http://maven.apache.org/enforcer/enforcer-rules/dependencyConvergence.html
