and stdio pipes (normally tunnelled by ssh)
I'm not sure what you mean by "stdio" pipes here. "byte-stream
protocol" might be a less imprecise form...
In particular, even though the Mercurial community
is committed to maintaining backwards compatibility in its
repository file format (binary) and the http- and stdio-based
wire
protocol, these interfaces are also considered Volatile. Future
project maturity may result in the upgrading of the stability of
these interfaces.
The interface taxonomy isn't all that good as a tool for describing the
inter-release interoperability of "private" file formats and protocols;
additional text is usually needed to describe the actual commitment
made.
Is the intent of making these Public interfaces to encourage alternate
implementations to read and write these file formats and protocols
directly?
If not, I'd think these should be considered some form of Private
(presumably Project Private) rather than Public.
The revised interface taxonomy is also very clear that there are
exceptional cases where breaking compatibility more frequently than
allowed by the taxonomy is OK. To quote the bulk of the "Exceptions"
section for the benefit of the Mercurial developers:
Although being absolutely stable tends to be good thing for
isotopes,
relationships and interfaces, there are times when it is in the best
interest of both the supplier and consumer to break the stability
commitment. The following list contains the known reasons to
violate
an interface stability commitment, but does not preclude others.
1) Security holes where the vulnerability is inherent in the
interface.
2) Data corruption (silent or otherwise) where the vulnerability
is inherent in the interface.
3) Standards violations uncovered by a change in interpretation
or enhancement of conformance tests.
4) An interface specification which isn't controlled by the
final implementation provider has been changed incompatibly
and the vast majority of interface consumers expect the newer
interface.
5) Not making the incompatable change would be incomprehensible
to our customers. One example of this would to have not
incompatably changed pcfs when Microsoft abandoned the 8.3
naming restrictions.
Incompatible changes allowed by exception should always be delivered
in the "most major" release vehicle possible. However, often the
consequences of the vulnerabilities or contractual branding
requirements will force delivery in a patch.
Every effort should be made to provide prominent and clear notification
to the interface consumers as far in advance of the change as is
possible and it may be appropriate to provide "impact mitigation"
tools.
---
Hope this helps.
- Bill
_______________________________________________
tools-discuss mailing list
[email protected]
