search

f3ath / cider

Tools for Dart package maintainers
https://pub.dev/packages/cider
MIT License
102 stars 16 forks source link

[Feature request] Handle pre-release strings #12

Closed rubenvereecken closed 3 years ago

rubenvereecken commented 4 years ago

pub_semver actually defines some special pre-release strings, eg alpha (1.2.0-alpha). This is about any sort of string that I'd like to tag my release with.

You already have support for strings, eg 0.2.1+foo or 0.2.1+foo.bar.1.2. However, I'm working on a Flutter project where the build (after +) needs to be strictly integer as it is used for versioning for both Android and iOS where it is called the "version code". My usual cider invocation goes

cider bump patch -b && cider bump build

This way the version string and the version code are always correlated. It does mean I need any pre-release strings to be in the first part, eg 1.2.0-alpha+42. The problem is that bumping the patch on this will remove the -alpha bit, whereas I'd like to keep it. Not sure if that's common/good practice actually.

My feature request is for cider to accomodate this somehow. I'm not sure what the best way would be. Either by allowing to patch on a version string so I can undo the cider bump patch removing it, or by considering them a special entity.

What do you think?

f3ath commented 4 years ago

Implemented in 0.0.5 please take a look

rubenvereecken commented 4 years ago

@f3ath I'm not entirely sure how to use this. Say I start off with

version: 0.1.39-alpha+40

What I'd hope to achieve is

version: 0.1.40-alpha+41

After cider bump patch -b:

version: 0.1.39+40

I can see the logic behind that maybe, it removes the -alpha bit. But that's the bit I'd love to keep.

After version: 0.1.39-alpha+41:

version: 0.1.39-alpha+41

This is great stuff.

Could we have the same behaviour for bumping patches? Or is this against some semver/Dart-flavoured semver rules perhaps?

f3ath commented 3 years ago

Closing this in favor of #17