Tim Jenness <[log in to unmask]> writes:
> Although, don't be surprised if Ole gets upset with you over the
> version number. Semantic versioning would suggest that a change of API
> breaking backwards compatibility should be a new major version.

Not really :-)

I differentiate between software version number and SOVERSION. Latter is
still 0 in Debian AST (and PAL), since there is nothing from upstream
(starlink) that would give me a better value.

However: I really would appreciate if you could maintain a SOVERSION
that is increased on an incompatible change. Otherwise there is a danger
(this time quite real) that things get broken: saods9 depends on AST and
needs to be recompiled or we will observe obscure crashes.

Specifically we are currently in a "transition" freeze (for Stretch) and
an (accidently) incompatible upload would cause some trouble.

> You should consider adopting semantic versioning. In essence, breaking
> APIs is a new major version, adding APIs is a minor version and fixing
> bugs is patchlevel change. Going from 8.3 to 8.4 and breaking APIs in
> the process will probably generate comment from him.

I'd just ask to have a separate number for that. Compatible changes
(added interfaces) are not a problem for us; we keep a symbols table for
each change and thus can generate backward compatibility lists
automatically.

I would however keep SOVERSION and the software version separate since
they serve different things. For example, CPL (from ESO) has currently
software version 7.0, but SONAME 26 (they seem to increase even during
development). But this is up to you.

Best regards

Ole