I think targeting experimental for breaking changes is a safer default
than picking unstable by default.

As per semver.org, for libraries without a public API, ie, version <
1.0, even minor updates can be breaking - even if it does not actually
break, most reverse dependencies declare a stricter dependency. Patch
updates are usually allowed when declaring dependency relations.

For example in ruby/Gemfile, we usually have

~> 2.0 (stable public API) vs ~> 0.9.0 (no stable API).

At least for library packages (this can packages starting with lib,
ruby-, python*- etc) we should do this by default.

For other packages also this might still be a safer choice.

Hi Praveen,

I need to admit that I perfectly understand your wish.  However, I think
this might go beyond the intended purpose of this small script which I
wrote to solve *routine* tasks.  It is not really intended to do
everything absolutely automated - developer checks should be done in
normal cases.  For instance I always to a `git log` to inspect what
the tool really did.  Somehow guessing a target distribution is a bit
more.  I also think that this should involve the release number - I like
to add some '~exp' at the end of the version string - others don't.

On the other hand we might consider different behaviour for certain
teams.  I just added in version 0.2 a whitelist for those teams who like
some debian/salsa-ci.yml file.  So if you are teams where it can guesses
from the upsteam version what target distribution is sensible and how
the version string should be designed I'd happily implement a patch.
For the use cases I have it is not sensible to do extra means in this
direction.

Kind regards and thanks anyway for this suggestion
    Andreas.