Source
Lindby•

How does this guarantee that comming major versions has a larger version code than the existing maintenance version?

6
acid2do•

The biggest issue with this approach is then delivering versions to beta testers, and then wanting to update the live users with a patch.

Exactly what happened here: https://blog.danlew.net/2018/03/15/how-to-screw-over-your-beta-users-without-really-trying/

The version code, being consecutive, will be a big problem in the future.

8
[deleted]•

[deleted]

1
0x800OP•

The plugin is obviously not a silver bullet. I use it for personal projects, where the problems you mention are rarely an issue. That said, it does offer a way to enhance the generated versionCode, but requires a bit of fiddling:

versioning {
  decorateVersionCode { code -> code * 100 + patchNumber }
}
2
rockpilpDeveloper (MyTrails)•

Great idea, and I like how you documented it.

One aspect you may want to document in more detail is how this relies on the git history. Most CI environments perform a shallow clone of the repo. How does this affect your plugin?

5
0x800OP•

I’m glad you like it! Great point about shallow cloning. My gut feeling is that it should be OK, but I’ll double check and make sure it’s part of the documentation. Thanks!

2
The_Mighty_Tspoon•

Hey Tadej! Guess who ;)

Sweet plugin!

Is there any performance impact when using this for day to day development? Or should it only be enabled in CI environments?

In theory, computing a git tag value every time can affect performance - see here (The section Avoid heavy computations).

Would be interesting to see some benchmarks on that though!

3
0x800OP•

Oh noes, it’s the code review police! :) I haven’t really thought about the performance, good shout! I’ll try to come up with some stats to either confirm or refute this is suitable for everyday use.

2
The_Mighty_Tspoon•

One related fun thing I learned the other day was that apply plugin: 'kotlin-android-extensions' was costing 5 seconds (on incremental builds), just for one @Parcelize implementation.

-1 to that!

2
0x800OP•

Did you keep kotlin-android-extensions? Replaced it with something else? Or (gasp) wrote the boilerplate yourself?

2
0x800OP•

I did a quick perf check on the linux kernel source. My MacBook (2.2 GHz Intel Core i7, 16GB ram) spits out this numbers:

$ time git describe --tags --dirty --always
v4.18-rc7-20-g527838d470e3-dirty

real	0m1.098s
user	0m0.310s
sys	0m0.500s

$ time git rev-list --count HEAD
768265

real	0m6.996s
user	0m6.634s
sys	0m0.339s

While the versionCode command is slower than expected, it’s most likely negligible for small and medium size projects (probably large too, unless they’re linux kernel large).

Git, for example, is pretty quick:

$ time git describe --tags --dirty --always
v2.18.0-321-gffc6fa0e3

real	0m0.567s
user	0m0.061s
sys	0m0.085s

$ time git rev-list --count HEAD
52126

real	0m0.757s
user	0m0.618s
sys	0m0.039s
1
anuragdadheech•

Good stuff.

2
0xKubo•

What if you use something like Gitflow and only tag your builds automatically on a successful CI build when pushed to master?

2
0x800OP•

You’ll end up with version names such as 0.1.0-2-g3cbf60f, which may or may not be ideal.

1
NewbieReboot•

Looks similar to https://proandroiddev.com/configuring-android-project-version-name-code-b168952f3323, but just cleaner. Any major differences?

2
alexfu1•

Seems similar but also very different to https://github.com/alexfu/androidautoversion.

1