Added 'dev' as a version bump rule to increment versions with .devM

[gaileyleseman]

This adds dev as a version bump rule for developmental releases. This was already implemented in poetry-core, I've just added the option to the cli.

This is my first contribution, I hope I followed the correct procedure!

Pull Request Check List

Resolves: #8718

• Added tests for changed code.
• Updated documentation for changed code.

[dimbleby]

if this is actually what it is doing then it is bugged, because the dev release is earlier than the non-dev release

[gaileyleseman]

Ah I see, thanks! I was (wrongly) treating the .devM similar as the .postM releases.
That makes the problem more ambiguous and that also explains this warning in poetry-core.

            warnings.warn(
                "Calling next_devrelease() on a non dev release is deprecated for"
                " its ambiguity. Use next_major(), next_minor(), etc. together with"
                " first_devrelease()",
                DeprecationWarning,
                stacklevel=2,
            )

I see the following options:

1. Always do a prerelease before adding .dev

        elif rule == "dev":
            if parsed.is_stable():
                new = self.increment_version(version, "prerelease", next_phase)
            new = parsed.next_devrelease()

2. Raise a ValueError when trying to increment with dev on a stable version

        elif rule == "dev":
            if parsed.is_stable():
                raise ValueError(
                    "Cannot use the 'dev' bump rule on a stable version because"
                    " the behavior is ambiguous. Please use 'premajor', 'preminor', "
                    " 'prepatch' or 'prerelease' first to indicate the next version"
                )
            new = parsed.next_devrelease()

3. If both options above are insufficient, close this MR and keep doing the .devM increments manually

❯poetry version --short 
1.8.0.dev0
❯ poetry version "1.8.0.dev1"
Bumping version from 1.8.0.dev0 to 1.8.0.dev1

Let me know what you think!

[dimbleby]

I don''t really mind what the resolution is - my personal practice is to edit the pyproject.toml directly: I don't find that poetry version is valuable enough to be worth the code, and so from my point of view this all is very niche.

However I do think that if the CLI ends up moving the version number backwards, where all of the other similar commands move it forwards - then that'll generate more bug reports than it fixes!

[gaileyleseman]

I see, I'm experimenting with automatically bumping versions through ci/cd pipelines, for which the poetry version command could be very useful.

I've updated the logic and the docs/tests such that the version number always moves forward.

[radoering]

In general, I think we should define the target behavior in #8718 first because it's ambigious. For example, we could also bump 1.0.2 to 1.0.3.dev0 instead of 1.0.3a0.dev0. (Both are correct.)

[radoering]

Still a decrement. (1.1.0a0.dev0 comes before 1.1.0a0.)

[radoering]

That's a decrement.

[github-actions]

This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.