request: preserving versionCode

aquadesk commented 2 years ago

Is there an existing feature request for this?

[X] I have searched the existing issues.

Command

melos version --preserveCode

Description

I have versionCode specified in yaml file

version: 2.1.1+3

and when I run version command, it drops the version code

The following 1 packages will be updated:

Package Name     Current Version   Updated Version   Update Reason
twenty_seconds   2.1.1+3           2.1.2             updated with patch changes

Version code should be unique for android deployment.

The following 1 packages will be updated:

Package Name     Current Version   Updated Version   Update Reason
twenty_seconds   2.1.1+3           2.1.2+4             updated with patch changes

Can we preserve the code and up the code with the flag? -p or -preserveCode

Reasoning

Version code should be unique for android deployment.

Additional context and comments

No response

Salakar commented 2 years ago

I don't think we should support this since the Dart convention is to drop the + after the version reaches 1.0.0 https://dart.dev/tools/pub/versioning#semantic-versions - specifically:

Although semantic versioning doesn’t promise any compatibility between versions prior to 1.0.0, the Dart community convention is to treat those versions semantically as well. The interpretation of each number is just shifted down one slot: going from 0.1.2 to 0.2.0 indicates a breaking change, going to 0.1.3 indicates a new feature, and going to 0.1.2+1 indicates a change that doesn’t affect the public API. For simplicity’s sake, avoid using + after the version reaches 1.0.0.

blaugold commented 2 years ago

I think the motivation for this issue is that in Flutter apps the version code is used as the build number, which should be incremented for each release. When you use melos to version a Flutter app I can see that dropping the version code would be inconvenient.

aquadesk commented 2 years ago

I love Melos :)

Especially because it is Flutter friendly.

I actually wrote up a script file to support this in my way keeping it in a separate file such as .version-code but it would be awesome to see melos supporting it in the future

💯

BenVercammen commented 2 years ago

I've been struggling with this too, that's how I landed here. The main reason I switched from mono_repo to melos, was that melos also automated versioning, but apparently not without caveats... Now it seems that melos is actually following the convention, so I decided to fix my problem in another way...

Just for the record, my problem was that when deploying the .aab file to Google Play, I got the following error: Google Play failed to upload artefacts. You cannot rollout this release because it does not allow any existing users to upgrade to the newly added APKs.

This is caused by the versionCode being set to the flutter.versionCode value, which is taken from the part after the +.

Since I build my app on codemagic.io, I was able to make use of an existing environment variable and changed my build.gradle file like this:

    ...
    defaultConfig {
        applicationId "my.app.id"
        minSdkVersion flutter.minSdkVersion
        targetSdkVersion flutter.targetSdkVersion
        // versionCode flutterVersionCode.toInteger()
        // use the [PROJECT_]BUILD_NUMBER env variable instead
        versionCode System.getenv('BUILD_NUMBER').toInteger()
        versionName flutterVersionName
        multiDexEnabled true
    }
    ...

So it's probably up to your CI/CD tool to fix the issue. Some helpful information:

I hope someone may find this helpful as well...

blaugold commented 2 years ago

Thanks @BenVercammen for linking the codemagic build versioning guide. It gives a good overview of how build versioning works in Flutter and how to approach it.

The build number might be different between iOS and Android app releases, and it's probably not a good idea to manage it in pubspec.yaml. I don't think Melos can help here in a good way.

aquadesk commented 2 years ago

Mostly build number could be identical across platforms

Thanks for looking into it.

egyleader commented 1 year ago

WorkAround

for me the simple solution is to minpulate flutterVersionName to be the version code dynamically , in your app module build.gradle change 👇🏻

defaultConfig {
        versionCode flutterVersionName.replace('.','').toInteger()
        versionName flutterVersionName
    }

obenkucuk commented 7 months ago

WorkAround

for me the simple solution is to minpulate flutterVersionName to be the version code dynamically , in your app module build.gradle change 👇🏻
defaultConfig {
        versionCode flutterVersionName.replace('.','').toInteger()
        versionName flutterVersionName
    }

This logic fails in some specific scenarios which are not very rare. if version 1.0.11 updated with major update, new version will be 2.0.0. because the predecessor versionCode was smaller than the other (1011 > 200), upload will fail

invertase / melos