mirror of
https://github.com/OpenHFT/Chronicle-Map.git
synced 2021-09-13 01:26:12 +00:00
70 lines
3.1 KiB
Plaintext
Executable File
70 lines
3.1 KiB
Plaintext
Executable File
= Chronicle Map 3 Versioning
|
|
Neil Clifford
|
|
:toc: macro
|
|
:toclevels: 1
|
|
:css-signature: demo
|
|
:toc-placement: macro
|
|
:icons: font
|
|
|
|
toc::[]
|
|
|
|
== Java implementation Versioning
|
|
|
|
The versioning format is as follows:
|
|
|
|
`<major>.<minor>.<patch>`
|
|
|
|
For example:
|
|
`3.14.1`
|
|
|
|
|
|
=== The <minor> number should be updated, when:
|
|
|
|
- a feature, or public API method is added.
|
|
|
|
- the behaviour of `ChronicleMap`, `ChronicleMapBuilder` or any other class or method or subsystem
|
|
is semantically changed.
|
|
For example, when configuration heuristics in `ChronicleMapBuilder` are improved, and
|
|
`ChronicleMapBuilder` configured the same way constructs a `ChronicleMap` with a different
|
|
number of segments, or segment's capacity, etc.
|
|
|
|
- any dependency is updated, even if only `<patch>` number is updated, e. g. `chronicle-bytes`
|
|
dependency is updated from `1.1.1` to `1.1.2`. This rule doesn't apply to dependencies to the umbrella POMs which merely determine versions of other dependencies (namely `chronicle-bom` and
|
|
`third-party-bom`), if the versions of actual dependencies don't change between those versions of umbrella POMs. Also, this rule doesn't apply to dependencies with Maven scopes of `test` or `provided`.
|
|
|
|
- bug fixes, performance optimization or feature addition requires to change the binary or
|
|
serialized form of Chronicle Map data store (therefore revise the Chronicle Map data store
|
|
specification, see below), or the binary replication protocol, or the serialized form of some
|
|
marshaller classes, that requires to [create new versions of classes](compatibility.md).
|
|
|
|
=== The <minor> number should not be updated, i. e. the next release could update only the "patch" number, when
|
|
:
|
|
- A bug fixed, in a way that doesn't make any working code to change its behaviour semantically.
|
|
- Performance optimized: some working code changes its performance characteristics,
|
|
but not semantics
|
|
|
|
During development after the release of the version `3.y.z` the library should be versioned
|
|
`3.y.<x+1>-SNAPSHOT`. As soon as changes made are substantial enough for the next released version
|
|
to update the "minor" number, the version should be changed to `3.<y+1>.0-SNAPSHOT`, *in the same
|
|
commit* these changes are made.
|
|
|
|
Suffixes `-alpha`, `-beta`, `-rc` etc. mean this is a pre-production release.
|
|
|
|
== Specification Versioning
|
|
|
|
The first Chronicle Map 3 production release designates the Chronicle Map data store specification, revision 1.
|
|
|
|
When the specification should be updated in a way that is not [backward compatible](compatibility.md#the-specification-compatibility), the revision should be updated (revision 2, 3, ...) and the Java implementation of this revision should have '<minor>' number updated in its
|
|
version.
|
|
|
|
During the development after the release of the revision `x`, while the specification is backward
|
|
compatible, it should remain versioned `x`. In the same commit where the specification becomes
|
|
incompatible, its revision should be set to `<x+1>-pre` until the next production release.
|
|
|
|
Releases and updates to the `<minor>` number in the library version should be synchronized with
|
|
updates to the specification revision number.
|
|
|
|
|
|
'''
|
|
<<../ReadMe.adoc#,Back to ReadMe>>
|