On 04/26/2010 02:43 PM, Chris Hostetter wrote:
I didn't follow the Version API relaxation thread (my fault: i thought it
was focused solely on how we were dealing with o.a.l.Version and lots of
smart people were talking in ernest so i left it to them to make smart
choices) but looking at this proposal, I'm at a loss to understand how
it's any differnet then what we do today: we have a trunk, we add lots of
features, and we document when compatibility breaks (and as a result rev
our version numbers accordingly) ... in contrast, we have the "release
branches" where we backport changes that don't break compatibility. the
only distinction seems to be this sentence...
: The stable line of development (on a branch) will get
: non-back-compat-breaking changes, and will be released more often (as
: minor releases and possible also .Z bugfix releases).
...i don't know that anyone would say we release "more often" off of hte
existing release branches, but that seems more an issue of practice then
procedure.
So I feel like i must be missunderstanidng the goal here.
My best guess: that what this is really suggesting is that "trunk"
*always* be targeted at the next "major" release (ie: 4.0, 5.0, 6.0,
etc...) and that development of minor releases (ie: 3.2, 3.3, ...; 4.1.,
4.2, etc...) happen on "more stable" branches off of the major version
release branches (ie: branch_3_0 forks off trunk when 3.0 is release,
branch_3_1 forks off branch_3_0 when 3.1 releases, etc...)
If i'm wrong, then can someone please explain it to me in a concreate
actionable way? (ie: specific examples of actions people would take
moving forward under this new procedure)
As I understand it:
Your guess is correct.
The goal is to have future development not be encumbered by bw compat
maintenance.
Trunk will not try to maintain backward compatibility. (As I see it
there is no longer any point to Version in trunk.)
It probably won't have deprecations.
There will be no 3.9 release that differs from 4.0 only in deprecations
removed.
Moving from 3.x to 4.0 will require users to be deliberate and careful.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
