fix: Don't fail when there are no releases

Fixes #342.

I was pretty sure the conclusion from #342 was that this wasn't really fixable for two reasons:

• the bump script has two required positional arguments (old version, new version) and passing nonsense is a breaking change
• the changelog generation requires a previous version

It is fixable (at least to me), here's my reasoning:

the bump script has two required positional arguments (old version, new version) and passing nonsense is a breaking change

Not necessarily as this only applies to the very first release. At that point one can tweak the script. In any case, I use 0.0.0 as the default version instead of an empty string just in case. That said the "breaking" part doesn't really apply as this would not affect any existing project (otherwise you are right, it is a marked departure from the original behavior, which is crashing).

the changelog generation requires a previous version

The workaround for this is just getting all the commits up to HEAD which just works?

I'd rather we fix this properly and deprecate the 2-arg release bump script and make a bump-version-v2.sh or whatever

The workaround for this is just getting all the commits up to HEAD which just works?

I assume you mean to the beginning of the history? HEAD is the current revision

I assume you mean to the beginning of the history? HEAD is the current revision

Up to HEAD from beginning. The entire commit history in short.

I'd rather we fix this properly and deprecate the 2-arg release bump script and make a bump-version-v2.sh or whatever

Why though? Having the old version available is definitely useful and making the script be called with 1 arg for the initial release and 2 args for the rest seems like adding unnecessary complexity.

What's your main concern here? I am lax as this only applies to new projects and shouldn't have any impact on existing ones.

I don't think the old version is useful. and I don't think sending a bogus value for the first release makes sense either

@asottile-sentry I cannot justify the change you are asking for from a cost benefit standpoint. Making a deprecation for all existing projects, forcing an analysis and migration with a way to manage a breaking change for a fix that only affects the first release of new projects doesn't seem cost effective to me.

What am I missing from your perspective?