Are we following the guidelines of http://semver.org? If so, should we declare that (possibly in the 4.0.0 release notes)?
Semver.org specifies that adding any deprecation warning would need to be done in a minor release and any removal of a deprecated feature be done in a major release. This is a departure from our deprecate+2 releases rule for removing features. There are enough bits of the API worth changing that I think we'll be spinning through major versions. If we strictly follow semver.org, we'll need to bump the major version for any backwards incompatible change, even if it's in scratchpad or some other volatile module. At the same time, anyone using a module that isn't actively developed, like hdgf, won't benefit from semantic versioning to know that there weren't any backwards incompatible changes to hdgf from 4.0.0 to 5.0.0. How do we want to manage this? Maintaining different package versions for each module sounds like a nightmare for devs and users alike. Do we rely on bugzilla and the changelog to convey this information, as well as our API Check build? On Sep 16, 2017 18:47, "pj.fanning" <[email protected]> wrote: I agree with Andi about using 4.0.0-SNAPSHOT as the release number. I'd like to make regular 4.0.x releases and to have 4.y release on a similar cadence to the existing 3.z releases (2 or so a year). -- Sent from: http://apache-poi.1045710.n5.nabble.com/POI-Dev-f2312866.html --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
