Some projects never break client code. I think that’s one extreme
that won’t serve us or our users well. To ease any pain associated
with breaking code, we do need to make it very predictable. And
making breaking changes at major release boundaries only achieves
that goal.
I think we're definitely agreed that we shouldn't make breaking
changes except in major releases. My comment - apologies if it wasn't
stated clearly - was that I'm hesitant to restrict ourselves to also
*announcing* upcoming breaking changes in major releases.
I agree that we certainly should avoid deprecating something in 2.9
and breaking it in 3.0, but deprecating it in 2.1 and breaking it in
3.0 (with requisite warnings, questions on user@) etc. seems
reasonable to me in general.
Curious to hear what others feel about that?
Frankly, I don’t know what to do here. Remove the section or keep
it. If you want to keep this section, could you please start it out
with “This applies to jclouds-lab and jclouds-labs only”?
I really don’t want us to get too distracted by this subject.
Indeed. Modified [1].
I see what you mean but wouldn’t that make backporting very
difficult if not impossible in some situations?
Could you explain? I would imagine that if we wanted to remove a piece
of functionality on master (and, of course, we don't *have* to do this
- I'm just not sure we want to ban it), we would:
1) Push a commit that deprecates the functionality we want to remove
and presumably adds an alternative
2) Backport that commit to the current release branch
3) If desired, push a subsequent commit to master to remove the
deprecated functionality
I understand now. What did you think of this alternative wording?
"Beta methods and classes will be promoted to non-beta status or
removed only in major releases (e.g. MAJOR.0)"
That sounds fine to me. It doesn't give any indication of *how many*
major releases you might have to wait, though. I'm perfectly OK of not
including such an indication if we feel it doesn't make sense, by the
way.
Thanks for the responses!
ap
[1]
https://wiki.apache.org/jclouds/DeprecationAndBetaPolicy?action=diff&rev2=6&rev1=4
