rubiconba / fastlane-plugin-flutter-version-manager

Fastlane plugin that is used to manage app versioning of Flutter project
MIT License
35 stars 11 forks source link

Version number from git inaccurately persisted in pubspec.yaml #3

Closed IAmJulianAcosta closed 3 years ago

IAmJulianAcosta commented 3 years ago

I see that there is one issue with having the commit time as a build number, and is that you can't have the real build number committed in pubspec.yaml.

As the build number is based on the previous commit time, at the moment someone commits, the commit time is not longer representing the right build number as is going to be always one commit behind.

For example if -apply runs before commit, the current version stored in pubspec.yaml will be the one in the previous commit, not the actual commit, and there is never a way to keep both in sync.

davormaricdev commented 3 years ago

Hi. Yes, you are correct. -apply argument takes current commit time and uses it as a build number. If you are going with the -apply approach, then you are right again, there is no way to keep the actual commit time in sync with commit time that was written in pubspec.yaml. May I ask you why do you need such behaviour? I can understand that you want to use it to track commit via commit time, but that would never be possible due to this offset.

Whole purpose of commit time as build number was to use it to bump build number seamlessly. Please refer to this blog post for more info.

IAmJulianAcosta commented 3 years ago

So this my use case:

I have a pre-commit hook that runs -apply so the version that is going to be built is stored in the commit, and I can use it as reference. After running, it generates the version.

Later on Jenkins I have to run -apply again in order to get the latest version (based on the commit), so the version that I'm pushing to the device is not the same that gets stored in the commit.

I think that a simple way to fix this is to offer an option to generate the version code from the past commit, or as a timestamp. So if -apply is running as a hook as I do, it will be linked to the current commit timestamp.

davormaricdev commented 3 years ago

Later on Jenkins I have to run -apply again in order to get the latest version

Can't you simply use -version or -code to read the stored version?

-version: Reads current version name
-code: Reads current version code
IAmJulianAcosta commented 3 years ago

Hi @davormaricdev, sorry, I couldn't answer on time.

I'm running -apply on jenkins in order to update pubspec.yaml and to display the version on the app.

What I think it can be done is to have an option to generate version code from current unix time, instead of latest git commit, that way it doesn't depend on commits, but in the timestamp -apply is run.

In this case, the version code is generated using a pre-commit hook, gets stored in the repo, and when jenkins builds it, it will be the same as the commit.

Do you think this can be done?