What do you hope to achieve by using continuous delivery for this library?
Why do your clients require a commit / pr build?
I think you're responding to a directive from above to be AGILE tm. Or the feeling that there is a Standard that, if followed, solves everything.
Unfortunately, this doesn't go away by adopting a devops model.
As you have pointed out:
- Release notes become difficult to observe
- The version repository becomes very dense.
- Client teams do not have the bandwidth to handle a high launch rate.
I would also add that it makes using the follow-up version more difficult and also gives a sense of impermanence to your library.
Not all compilations have to be released, but then where do we draw the line?
Obviously, having a show waits a full year, just screams of wasted potential. But then, days releasing each internal change that is needed but has not yet produced fruit.
There are two ways to think about this: function or launch.
In this world, the priority is in a set of functionalities whose value is low / negative when released little by little, but high when released together. This is particularly true if users have to be retrained, and business processes have to be updated.
In this case, it is best to have the library spanned through one or more sequences. When a transmission is viable, it is delivered in master, producing an official compilation. Builds of the stream branch are built, but never released (or released to a test service, not released).
This has the potential to do Big Bang merges, but on the other hand it allows your CI pipeline to just release every build from the master.
In this world, the priority is to set expectations for updates with customers. This is when customers have to make an effort to make sure they are up to date and compatible. Sometimes it is called a launch train, if the change is not yet ready, the train is lost.
Generally, you will want to provide two variants of your library in this model. An LTS variant (stable API, bug fixes, perhaps very stable additive changes) and a current variant (all changes including removed / altered API calls). You may even want to run an old LTS and a new LTS over a period of time to give clients a window to access.
In this case it is different since several branches are making public launches. Each cycle, the compilation released was the last successful one. This is usually the case of promoting the package from a development / test repository to the launch repository. But that depends on your packaging tool.
This leads to the case where there may be no release in a given cycle since nothing has changed. Which complicates the automation of this.