[pydave]

Is that because they're parsing porcelain output? Or is git's plumbing machine-readable but not well specified?

But git users are more familiar with porcelain so I wouldn't be surprised if they parsed that for an initial implementation.

It sounds like plumbing shouldn't break as often as you imply:

> The interface (input, output, set of options and the semantics) to these low-level commands are meant to be a lot more stable than Porcelain level commands, because these commands are primarily for scripted use.

https://schacon.github.io/git/git.html#_low_level_commands_p...

However, doesn't seem like they're nearly as rigorous as you hope.

[jiggawatts]

> Is that because they're parsing porcelain output? Or is git's plumbing machine-readable but not well specified?

From what I've seen, they're using the latter, but breaking changes are still introduced.

Either way, the output of UNIX-like command-line tools is inherently weakly typed and often completely unspecified.

PowerShell for comparison ships every module as both a user-interactive CLI command (with parameter tab-complete!) and as a programatically usable dynamic library. They're inherently one and the same, there's only one interface that does both. The API returns .NET objects and is strongly typed. There is no parsing step at all. If you load a given version of a library, you'll always get the expected types in the results.

Speaking of which, PowerShell uses semantic versioning for modules and can have multiple running side-by-side.

The future is here, it's just not very evenly distributed.

[pastage]

Semantic versioning still break clients (so what do you mean with multiple versions?). I would say that if you are handed a new version of a binary that spits out text, it is usually much easier to fix that than handling an API with objects.

I have failed to use PowerShell seriously many times, I am always let down by the opaqueness of it. (Which I agree is a common complaint against bash from inexperienced users)