I think that a transition to 4.0.0 would indicate that things are different. So maybe a repackaging is in order.
Semver states that anything with a 0.x.x version can contain breaking changes at any time. It is a pre-release kind of thing. Our documentation states that only the Excel package is stable, so I would expect that only Excel would get a 4.0.0. Everything else would still be at 0.x.x. As an interface gains enough stability to bring it out of the experimental stage we could give it a stable version number. We could have users use something like Maven to manage dependencies. I would break packages into jars like this: CORE - All common packages, file system (for now) v4.0.0 EXCEL - HSSF and XSSF v4.0.0 SCRATCHPAD - Everything else for the moment v0.4.0 Yes, we wouldn't be able to remove depreciated stuff as frequently, but I don't see that as a big problem. We simply don't have to maintain deprecated things as rigorously, when someone says a deprecated API has a bug, we point them to the replacement. On Sat, Sep 30, 2017 at 4:57 AM, Javen O'Neal <one...@apache.org> wrote: > 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" <fannin...@yahoo.com> 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: dev-unsubscr...@poi.apache.org > For additional commands, e-mail: dev-h...@poi.apache.org >
