You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
An example of a change that could introduce a version mismatch between rest-layer and supporting libraries for end-user, is #62.
Minimum solution
To allow end-users to better cope with minor breaking changes before a rest-layer v1.0, and to improve the ability end-users have for reproducibility, I propose to as a minimum tag a release v0.1.0 following semver conventions.
How to handle breaking changes
According to the semver spec: item 4, versions 0.y.z are for initial development, and anything may break at any time. However, I suggest that for a breaking change pre v1.0.0, MINOR (y) needs to be incremented. I.e. there should be no breaking changes in a PATCH (z) release.
For additional stability only
To futher allow people to minimize the risk of unpredictable behaviour due to version mismatch, I suggest that supporting repositories such as rest-layer-mongo etc., gets a manifest file describing which rest-layer version they require. I suggest this version number to be locked to MAJOR and MINOR pre v1.0.0. E.g. with Glide syntax:
An example of a change that could introduce a version mismatch between rest-layer and supporting libraries for end-user, is #62.
Minimum solution
To allow end-users to better cope with minor breaking changes before a rest-layer v1.0, and to improve the ability end-users have for reproducibility, I propose to as a minimum tag a release
v0.1.0
following semver conventions.How to handle breaking changes
According to the semver spec: item 4, versions
0.y.z
are for initial development, and anything may break at any time. However, I suggest that for a breaking change pre v1.0.0, MINOR (y
) needs to be incremented. I.e. there should be no breaking changes in a PATCH (z
) release.For additional stability only
To futher allow people to minimize the risk of unpredictable behaviour due to version mismatch, I suggest that supporting repositories such as rest-layer-mongo etc., gets a manifest file describing which rest-layer version they require. I suggest this version number to be locked to MAJOR and MINOR pre v1.0.0. E.g. with Glide syntax:
Until an official Go manifest format is defined, I suggest relying on a Glide manifest.
EDIT: Corrected some mistakes, including referring to a lock of MAJOR and PATCH.
EDIT 2: Added headings.
The text was updated successfully, but these errors were encountered: