Jose Luis Rivero

Hey Matias: Thanks for answering that fast. Some inline comments: > The way I see it, we should support it with a CMake option: > > * At CMake time...

> Eugene has suggested that rather than renaming every lib to OgreNext, just bake the version number. > > e.g. `libOgreMain.2.4.0.so` and `OgreMain.2.4.0.dll`, `libOgreHlmsPbs.2.4.0.so` etc; without using sym links. >...

> Oh wait, I understand now. The problem is that we're constantly switching between ABI stability mentalities. Sorry, I did not explain it correctly. > Yes agreed, with 100% ABI...

For reference, I've created this patch in Debian https://salsa.debian.org/ogre-team/ogre-next/-/blob/master/debian/patches/use-ogrenext-names-for-libs.patch which is only limited to the components and plugins used under UNIXes there. I can submit it in the form of...

Hello Matias, thanks for working on this, some small comments: > Therefore I propose OgreNext follows the following convention: > > * `PATCH` can only be bumped as long as...

> > I'm not sure I understand. We won't break the ABI for PATCH bumps. > > Are you saying the bumps to MINOR should also maintain ABI compatibility? >...

Thanks Matias, +1 for the proposal.

> I'm not sure if it will break anyone to make python required for build, but it may be worth checking with @j-rivero Since this is changing ruby by python...

> This pull request addresses a hard build requirement of generating the `EmbeddedSdf.cc` c++ code file, so I don't think it could be an optional dependency umm I see. As...

> we should improve the console error message for this: [osrf/gazebo#2869](https://github.com/osrf/gazebo/issues/2869) Let's start improving the user information until a proper fix is made: first step https://github.com/gazebosim/sdformat/pull/1171