On Dec 23, 2003, at 5:47 PM, Justin Erenkrantz wrote:
> If you took A'' and replaced it with A'' (i.e. no major version gap
> between removing APIs or compatibility), I think the APR versioning
> scheme matches this pretty closely in its spirit (if not precise
I'm not sure I follow your "if". I think there's a significant
difference between the APR scheme and the one I described; basically,
I've upshifted all the constraints one level. APR allows API change
with deprecation over minor release changes (A.B.*->A.B'.*), where I
restricted that to major releases (A.*.*->A'.*.*); similarly, APR
allows true incompatible changes over major releases, where I allow
that only over two major releases, with deprecation or
upwards-compatibility support over single major releases.
> I'm willing to guess that commercial software might have a harder time
> supporting parallel branches, but that's a hunch. ;-) -- justin
My experience is that commercial software supports quite a few *more*
parallel branches than open source. Easy or hard, it's inescapable.
At Informix, we maintained around four concurrent major releases, each
with with around half a dozen minor releases, each of those with a
couple dozen port branches, and each of those with several dozens of
patch twigs. Yes, that's hundreds of branches and thousands of twigs.
Actively supported. ClearCase's support matrix isn't much smaller.
In the context of this discussion, that's not one-up-manship: that's
the class of customer demand I expect to have to support with SVN in
CollabNet (well, portability's easier now than it once was, so we can
deflate the couple dozen port branches considerably). I don't need to
shackle open-source SVN with the same ball-and-chain, but as I said I
need to be able at least to map between the two systems.
8000 Marina Boulevard, Suite 600
Brisbane, California 94005
Received on Wed Dec 24 03:01:16 2003
- application/pkcs7-signature attachment: smime.p7s