Please familiarize yourself with existing jclouds versioning scheme,
which I will summarize.
Thanks for putting this together, Gaul! Maybe it's just me, but I get
a feeling we're actually having two discussions at once here, and it
might make sense to split them:
1. We can make life easier for our users (and new committers!) by
better documenting our deprecation policy and release cadence.
2. Does our current deprecation policy and versioning scheme make
sense, and do we want to change them?
From what I can see, the former discussion is not really contentious.
I'm pretty sure users will not automatically *look* at the deprecation
policy, and I think good Javadocs are much more critical here. But
it's something we can refer to in release notes and point to for new
committers, and so I think it would be useful.
Publishing a release cadence also seems like a no-brainer: users have
repeatedly asked for this, and I think minor releases at 6-week
intervals seemed acceptable.
The second topic is more contentious. My take is roughly that the
debate is essentially "benefit in terms of predictability of sticking
with the current scheme" vs. "benefit of moving to a different scheme
that is probably more widely adopted elsewhere". Or, looked at a
slightly different way, "predictability for existing users vs.
predictability for new users".
I don't recall seeing any direct user requests or questions in this
area, so I personally find it harder to come down on either side of
this debate at this point.
My suggestion would be:
1) We document the release cadence and deprecation policy as it is
*right now*. We have to decide on a place for that, but the Wiki seems
as good a place as any. We already have [1] and would then need to add
a Release Cadence/Roadmap page. For the version numbers in the
Roadmap, we would stick with the current scheme or simply say "MAJOR"
and "MINOR" with something like "(provisionally 2.1.0)" or so next to
the versions.
2) We continue the discussion about *modifying* the deprecation policy
and versioning schemes as needed:
a) removing deprecated code in MAJOR+2 vs. MAJOR+1 as currently
b) moving from MAJOR = X.Y.0, MINOR = X.Y.Z to MAJOR = X.0.0, MINOR =
X.Y.0, PATCH = X.Y.Z
Regards
ap
[1] https://wiki.apache.org/jclouds/DeprecationAndBetaPolicy
