: Big changes, that'd be destabilizing if attempted on the stable
: branch, would be done only on unstable (= trunk).
:
: More "normal" changes, which can still include deprecations/some back
: compat, would be done on the stable branch and unstable.
...
: By segregating the big changes away from stable we should be able to
: keep stronger back compat on stable. We also save our resources not
: building costly back compat layers that, because of their complexity,
: bring their own problems. Also, our release numbers are more
: "standard" -- the .0 release will have major changes (unlike today
: where is has no changes except removal of deprecations).
Ok .. I think i'm caught up.
My vote: +0
I like the idea changing our release/branch process so that every major
release (ie: 4.0) results in he creation of two branches: one for bug fix
release like we have now (ie: branch_4_0 where patches for releases 4.0.1
and 4.0.2 would be committed) as well as new branch for minor releases
along that major line (ie: branch_4 where patches for release in 4.1 and
4.2 would be committed instead of doing minor releases off of hte trunk
like we do now) with trunk now becoming the place where changes targeting
hte next major release (ie: 5.0, 6.0, 7.0) can be commited.
My concern is that this proposal essentially requires that our current
back compat "contract" be eliminated in favor of a looser "we'll document
what's changed and try to provide migration tools" type policy. What i
worry about is that if we do this w/o agreeing on some "higher precident"
guidelines on what exactly will be "ok" back-incompat changes to make
between major release, and what is "not ok" to hcange because it
introduces too big of a migration gap, then this could result in major
versions that are so widely differnet hte community gets fractured, with a
big chunk of users never upgrading from 4.X to 5.X because the API and
index formats are too widely different and the migration process is too
cumbersome (ahem: maven1 and maven2)
That said: I don't know that we can ever hash out where the "line which
should not be crossed" is on compat changes w/o trying stuff and seeing
what happens, and i don't personally have any better suggestions, so i'm
certianly not going to stand in the way.
-Hoss
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
