Danek Duvall writes:
> follow that change, then we'll file an obsolete case, and maintain the old
> name in parallel with the new as long as is necessary (because even
> Committed interfaces can be removed at a Minor release boundary with
> appropriate procedure).
Right.
> > > This project requests a minor release binding.
> >
> > For what it's worth, I think this would be fine as patch/micro.
>
> Fair enough. I don't know if Stephen has the intention of putting this
> back into S10.
It's just an expectation-setting thing. Patch/Micro allows you to
ship in any larger release, such as a Minor. If you say "Minor"
release, ARC members don't always think, "oh, he doesn't intend to
bother with a patch." Instead, they sometimes think, "what's the
issue here that makes this project particularly inappropriate for a
patch; what am I missing?"
> > > hg commandline Volatile
> >
> > Volatile means that people can't write reliable scripts that use it.
> > Is that right?
>
> Erm. Good point. I think you're right that certain subcommands have a
> greater stability than others, and some options more than others. Doing
> this properly will explode the interface table. I'll ask for Bryan's input
> on the stability, but I'll take a crack at it. I think we can call most of
> the important parts Committed, by the same reasoning as above, and
> Uncommitted would still require contracts to use.
It doesn't have to explode _this_ table, but there'll have to be a
reference somewhere. The table could just say something like this:
hg core command line Uncommitted
hg other command line Volatile
with the contents of "core" and "other" defined somewhere else.
--
James Carlson, KISS Network <[EMAIL PROTECTED]>
Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
_______________________________________________
tools-discuss mailing list
[email protected]
