Bumping to a prerelease version

[tmke8]

It would be great if it was possible to bump versions to 1.2.3.dev1, 1.2.3a3, 1.2.3b2, 1.2.3rc4 and so on. (As specified in the version scheme.)

There is some prior art in poetry and hatch (links are to the docs of the version bump commands).

Something like this might make sense:

• devmajor, devminor, devpatch: same as major, minor, patch but add .dev1 at the end
• next-phase: map .devX -> a1, aX -> b1, bX -> rc1, rcX -> , -> .post1
• prerelease: increment the number within the prerelease level, so a1 -> a2, rc2 -> rc3, and so on
  • this bump command would fail if the current version is not a prerelease version

EDIT: in case .dev and .post releases are too unusual, just a, b, and rc would also work

[T-256]

Like it. here is my point of view:

0.1.0: major -> 1.0.0: minor,a -> 1.1.0a1: a -> 1.1.0a2: patch,rc -> 1.1.1rc1

new possible values for --bump cli option are a, b and rc:

• They SHOULD be joined to major, minor, patch with comma: 1.0.0: minor,a -> 1.1.0a1
• They CAN be increment by multiple calls when already in prerelease: 1.0.0a1: a -> 1.0.0a2: rc -> 1.0.0rc1
• They CANNOT have support for backward: 1.0.0rc1: a -> ERROR: dumping (rc -> a) is not acceptable

some decisions have to made:

• Also set patch as default when going from release to prerelease. Then it's not mandatory to use comma-joined --bump patch,a. Instead this also works same: 1.0.0: a -> 1.0.1a1
• prerelease numbers should start from 0 or 1? (both hatch and poetry startswith 0)

[tmke8]

Yeah, that's also possible. That's essentially how hatch does it. I'd be fine with this.

(I also initially thought that there should be a dot before a, b, rc but the official regex doesn't allow it:

[N!]N(.N)*[{a|b|rc}N][.postN][.devN]

)

[T-256]

(I also initially thought that there should be a dot before a, b, rc but the official regex doesn't allow it:

Oh, Right! Edited the comment.

[geodab]

Just wanted to chime in to say that additional options for bumping all of the standard version segments would be welcome, including support for development versions .devN. For some context, a good use case for development versions is for deployment to an internal snapshot repository, which is in contrast to pre-release versions that may be public (but could themselves also have developmental snapshot versions deployed for internal testing prior to public release).

I'd also like to suggest, in relation to #757, that if there should be a default segment to bump when no segment qualifier is specified (rye version --bump), that the most specific existing segment be implied. For example, if there is already a .devN segment then it would bumped, otherwise the most specific segment that is present would be bumped, whether that is a post-release .postN, pre-release {a|b|rc}N, or the last N of the release version N(.N)*.

[jeeftor]

I think I just ran into this issue. I'm trying to migrate from a poetry setup to rye - and I used to be able to publish tons of pre-release or dev versions to test.pypi .

It seems with rye I only get to publish a single one

Like - so.