Sean Busbey wrote:
On Feb 16, 2015 2:17 PM, "Christopher"<[email protected]> wrote:
In favor of stability, I think we should re-add anything that was removed
prematurely, where it makes sense to do so. Some things, like the
mapreduce.lib.util classes I believe were removed due to the fact that it
inadvertently fell into the definition of public API when it never should
have been, and were moved shortly after clarifying what precisely was
included in "public API" (I believe they were added prior to that
definition being added, if I'm remembering correctly). I'm not sure it
makes sense to reintroduce those... because they were never expected to be
used by users anyway (and therefore were moved prior to adopting semver),
but if we really want to be strict about that, we can do those, too.
Since the mapreduce.lib.util classes have been published as public api
under semver (at a minimum in 1.6.2), we should maintain them if we don't
want to make a major version bump.
In general, I think we now want to avoid taking away methods, which means
no bumping major version, unless/until there's compelling API changes that
would warrant such a move. So, I'm in favor of keeping it at whatever it
takes to be 1.7.0 for now.
+1
Unless someone else beats me to it, I'll wait a couple days to see if
there's any more discussion and then file a blocker on 1.7.0 with the
current gaps.
This sounds good to me too. It sucks that we screwed up with stuff that
we considered to be "internal", but, unless there's something that
fundamentally prevents us from reinstating the old stuff, I would think
that's the best path. If it's not feasible to reinstate stuff, we should
enumerate the specific instances and reasons why we can't/won't
reinstate and then decide if we just want to apologize and ask for
forgiveness from users.
