I'm the developer and maintainer of a C++ library, call it libfoo.

There used to be just one variant of it; and I've made several numbered releases. Last year, I've created a second variant of libfoo (call it var2). The thing is, despite the new variant covering all functionality of var1, it uses a different approach. I won't go into the details (unless you think they're important), but - both the original var1 and var2 continue to be relevant, and I would like to release both, going forward. At the same time, they clash: Some of the API (and the code) is exactly the same; some is API-identical but with different implementations; some the API is slightly different (different signatures for the same function, different types or definitions of types etc).

Currently, I have these two variants on two different branches in the same GitHub repository; and the releases only come from the first. And whatever I think of doing about it, I am worried of potential consequences:

• If I release the new variant using the same library name and repository, and a higher version number, it suggests the existing variant is deprecated and un-updated.
• If I release the variants going back-and-forth between variants, it would be confusing and break things.
• If I release both variants together, I'm releasing two clashing libraries which can't really be used together. Plus, what would I do about the library name?
• If I split the variants into separate repositories, I'm afraid people will fail to notice at least one of the variants.
• If I release both libraries together, I'm essentially guaranteeing large-scale code duplication (but can I avoid it at all?)

How would you recommend managing this situation with respect to: Repositories, versioning, releasing and release location, naming of everything (include inside the code and in the documentation), explaining the situation in README's, etc?

I would especially be interested in answers backed by your own experience with similar situations.

_{If you want to take a peek, the library is here.}

I'm the developer and maintainer of a FOSS C++ library, call it libfoo.

There used to be just one variant of it; and I've made several numbered releases. Last year, I've created a second variant of libfoo (call it var2). The thing is, despite the new variant covering all functionality of var1, it uses a different approach. I won't go into the details (unless you think they're important), but - both the original var1 and var2 continue to be relevant, and I would like to release both, going forward. At the same time, they clash: Some of the API (and the code) is exactly the same; some is API-identical but with different implementations; some the API is slightly different (different signatures for the same function, different types or definitions of types etc).

Currently, I have these two variants on two different branches in the same GitHub repository; and the releases only come from the first. And whatever I think of doing about it, I am worried of potential consequences:

• If I release the new variant using the same library name and repository, and a higher version number, it suggests the existing variant is deprecated and un-updated.
• If I release the variants going back-and-forth between variants, it would be confusing and break things.
• If I release both variants together, I'm releasing two clashing libraries which can't really be used together. Plus, what would I do about the library name?
• If I split the variants into separate repositories, I'm afraid people will fail to notice at least one of the variants.
• If I release both libraries together, I'm essentially guaranteeing large-scale code duplication (but can I avoid it at all?)

How would you recommend managing this situation with respect to: Repositories, versioning, releasing and release location, naming of everything (include inside the code and in the documentation), explaining the situation in README's, etc?

I would especially be interested in answers backed by your own experience with similar situations.

Additional information:

• For me personally, var2 is "the successor" of var1; but there are reasons why many users might be perfectly fine with var1 and not want/need var2.
• I am developing this library independently, so there are no large clients which need to be placated one way or the other.

_{If you want to take a peek, the library is here.}