Package naming when no backward compatibility at all?

["J. Lewis Muir" <jlmuir%imca-cat.org@localhost>]

Hello!

I'm looking into creating pkgsrc packages for software that explicitly
does not follow Semantic Versioning and does not promise API nor ABI
backward compatibility even for a patch-level version change.  There
could be other packages in the same software ecosystem that depend on
this package or other packages with the same policy.  (Unfortunately,
many do not say what their policy is.)  What's the best way to handle
packaging the packages in such an ecosystem?

Since one strategy in pkgsrc seems to be to put the version in the
package name (e.g., lang/python27, lang/python313, security/gnupg, and
security/gnupg2), I initially thought that I could do the same, but then
I realized that since a backward incompatible change could be made for
any version change, even a patch-level version change, I think I'd have
to put the entire version in the package name (e.g., for foo version
7.0.8.1, I'd have foo7081).  But then I'd have a bunch of versioned
packages.  Maybe that's the best I could do, but I'm not sure, which is
why I'm asking.

Maybe another approach would be to include the <major> or <major><minor>
part of the version in the package name, but then declare a specific
version of that package in all packages that depend on it.  I'm not sure
this would even be possible, I'd have to study more, but I thought I'd
ask before spending too much time investigating this approach if it's
doomed to fail, or if there's a much saner approach that someone else
might suggest.

Yet another approach could be to package all the software in the
ecosystem together in one pkgsrc package.  I'm not a big fan, but it
would solve the dependency difficulty, I think, because then there'd be
no dependencies between packages from the same ecosystem since they'd
all be bundled into one monolithic package.

Thank you,

Lewis