That's a different story and a monorepo has zero effect on that. The versioning that was mentioned before was versioning of the services themselves, i.e. this build produces version 1.5.4, next build is 1.5.5 etc. We don't do that any longer since moving to a monorepo. We deploy by commit hash basically.
That is way different from providing v1 of your API and changes come out in v2 of the API while you also still provide v1 of the same API. You can (and we do) do that perfectly well with or without a monorepo. Mostly for the public API. Internal API's often don't need to do versioning and one can go with backwards compatible changes and/or rolling a change out over multiple commit deploy cycles.
Some of this will depend on your size I suppose. The larger the org, the more services etc. the more stable versioning I would suppose happening.
I do agree to some degree with that (I'm the OP not the siblings :)). We just have to define what small means. Netflix or Google are way up there in scale. In relation to them we are small. We also don't actually have microservices vs. what I'm reading about Netflix's architecture. We probably have "macroservices" in comparison with them but we definitely aren't one monolith. We got a bunch of "small monoliths" so to speak.
That said, we're not small either. In our niche, which you might recognize if I said more, we're the top solution customers choose (but I won't go into much more detail than that for obvious reasons).
I actually couldn’t agree more. Figuring out what “small” means really is the key and that thoughtful level of analysis is what’s really important for determining what the right architecture is for a business. I must’ve articulated my thoughts poorly earlier, while I’m not crazy about monoliths, I’m not opposed to them either. It’s the monorepos that contain many monoliths that concern me. Microservices in general are hard to execute on, and even the most successful companies that have realized microservices have monoliths running somewhere in the background. Your enterprise sounds interesting and they’re fortunate to have such a self reflective engineer on their team.
That is way different from providing v1 of your API and changes come out in v2 of the API while you also still provide v1 of the same API. You can (and we do) do that perfectly well with or without a monorepo. Mostly for the public API. Internal API's often don't need to do versioning and one can go with backwards compatible changes and/or rolling a change out over multiple commit deploy cycles.
Some of this will depend on your size I suppose. The larger the org, the more services etc. the more stable versioning I would suppose happening.