On Tue, Sep 01, 2009 at 09:21:09AM -0700, John Plocher wrote: > On Mon, Aug 24, 2009 at 10:15 AM, Nicolas > Williams<Nicolas.Williams at sun.com> wrote: > > ? ? Banishing would-be Volatile stuff (e.g., because we have no i-team > > ? ? committed to supporting it) to /contrib won't absolve us when the > > ? ? upstream community breaks compat and we blindly ship the broken > > ? ? version. > > I believe you might be making an invalid assumption - that > incompatible changes in a component are somehow automatically and > always an indication of brokenness.
Actually, I wasn't. The points of my two posts in this sub-thread were: - The ARC should stay out of design issues (in this case the design issue of using Tcl to configure shell environment modules); - /contrib is a not good place for Sun projects to integrate into -- aim for /dev & /release if you can; - What is the architectural status of /contrib? IMO: none. /contrib is for third party contributions that are not yet ready to integrate into /dev & /release; - What to do about FOSS backwards compatibility breakage? (This was in my follow-up.) My suggestion: documented stability levels can and should be used to set expectations, but we need to be much more flexible with respect to backwards compatibility, and for the reasons that you pointed out (i.e., we're in violent agreement). Specifically, IMO: we should have very frequent Minor releases, or at least treat releases as "Minor for some things, Mico/Patch for most things", or otherwise allow for out of cycle breaks, plus suitable warnings on breaks. Alt. description: keep existing ARC interface taxonomy, but make it easier to make out of cycle breaks by adding to the release binding taxonomy. > The job of the ARC is to balance these conflicting requirements in a > way that does the least violence to the players - ... Yes. But with the current rules the ARC continues to strongly favor committed interfaces and backwards compatibility. I-teams therefore tend to prefer going with Volatile. But Volatile isn't useful for setting expectations. Committed and Uncommitted are, but they are too strong too. It ought to be possible for an i-team to go with Committed or Uncommitted if they believe some FOSS is stable (e.g., APIs from MIT krb5) and still make out of cycle backwards incompatible updates when the upstream community does it, there's no funding to avoid the problem the old-fashioned way. The vast majority of the time upstream will manage to stay backwards compatible, so the majority of the time Committed and Uncommitted will be much more useful than Volatile. > ... The question isn't "should we provide a new > version?", but rather "how can we provide a *set* of versions that can > be used to meet the various needs articulated above?". Sometimes you get into DLL hell if you provide multiple versions. At least with direct binding that's less likely than it used to be. We might even need to deliver more than two versions of some FOSS. > The easy case is when a component evolves in only compatible ways. > We've got that idiom nailed. Now we need to expand our abilities to > encompass the not-so-easy cases. Yes. The practically inescapable conclusion is that we should just allow out of cycle backwards incompatible changes (after some teeth gnashing, perhaps), with suitable warnings, and preferably have frequent Minor or Minor-for-some-things (and even Major-for-some-things) releases. Nico --
