[+1]: adopt semver 2.0.0 (http://semver.org)
[+1]: adopt additional strictness to require documenting deprecation for at
least 1 major release before possible to consider in the next major release
[+1]: adopt additional strictness to ensure forward compatibility between
bugfix releases
[-0]: start operating under whatever rules we adopt as of the master branch
[-0]: keep the master branch named 1.7.0
[-0]: define scope of these versioning compatibility rules to be our
current definition of "public API" and the wire version
As I said down below, I don't think trying to fully adopt semver when
we're still on 1.X is going to work out well because we're missing the 3
necessary version components. I think we should continue to operate as
we had and just address whatever concerns devs have until 2.0.0.
Also, as Keith very well stated already, wire compat is a new guarantee
and, if we do decide to make such a guarantee, we should have some
mechanism in place for the first such release we make with the
guarantee. A quick solution here is to have a champion behind the
wire-compat testing who can shepherd it into the targeted release.
Christopher wrote:
It would be helpful to this thread, if we can get some informal votes on
the following propositions:
[ ]: adopt semver 2.0.0 (http://semver.org)
[ ]: adopt additional strictness to require documenting deprecation for at
least 1 major release before possible to consider in the next major release
[ ]: adopt additional strictness to ensure forward compatibility between
bugfix releases
[ ]: start operating under whatever rules we adopt as of the master branch
[ ]: keep the master branch named 1.7.0
[ ]: define scope of these versioning compatibility rules to be our
current definition of "public API" and the wire version
I'm going to assume it's a given that if any exceptional situations arise,
we'll handle those through further discussions/voting, as appropriate.
--
Christopher L Tubbs II
http://gravatar.com/ctubbsii
On Thu, Dec 4, 2014 at 2:09 PM, Josh Elser<[email protected]> wrote:
Christopher wrote:
On Wed, Dec 3, 2014 at 1:41 PM,<[email protected]> wrote:
> +1 to semver
+1 to 1 major release before removing deprecated items
+1 to forward compatibility between bugfix releases
What's the version # for the master branch if these rules are applied?
Well, I'd say1.7 still, since it is consistent with our existing rules
for
determining a "major" releasetoday, *and* it matches semver definition
of
a "minor" release, because it doesn't break backwards-compatibility
compatibility from1.6 (with one tiny exception of dropping
Instance.getConfiguration()... because it was an exceptional situation
discussed in previous threads; if people are uncomfortable with that
exception, I can return it to the API, if it helps achieve consensus
here).
Sounds right to me.
When we actually have code to land in Apache for 2.0.0, I figured we'd
break 1.7.X off to branch named "1.7" and master would become 2.0.0. We can
have some feature branch in Apache off to the side to make sure 2.0.0
development can happen in a shared environment before making the above
switch.
