[Feature Request] Support for app version

[adesrosiers]

Would be awesome if this supported failing the build when a certain app version is reached:

@RemoveThis(version = "1.0.1")

[Stuie]

I believe this would require making a gradle plugin. I need to look into it before committing to it.

[vanniktech]

Read it from the BuildConfig ;)

[Jawnnypoo]

@vanniktech Would he be able to read the BuildConfig of the app, and not just the library's BuildConfig?

[vanniktech]

See which class was annotated with @RemoveThis and then get the package name of it. Then for each segment try getting the BuildConfig.

Imagine MyClass is annotated:
com.my.package.name.feature.ui.view.MyClass

then just try getting Buildconfig via:

com.my.package.name.feature.ui.view.BuildConfig
com.my.package.name.feature.ui.BuildConfig
com.my.package.name.feature.BuildConfig
com.my.package.name.BuildConfig
com.my.package.BuildConfig

at some point you'll get it and then you can go and use it.

[Jawnnypoo]

Heh, that could work. Although it would be problematic for if you have a seperate package name from your appId (such as if you were using an imported third party library or something).

Possibly you could also do something like context.getPackageName() since that will give you the apps package name and then assume the BuildConfig is under the same package name, though this is sometimes not true also if you are doing something like appending release or debug to the end of the package name on build flavors.

[vanniktech]

There is also this which is something they might work on and with it you'll get the application id

[Stuie]

At this point the library works for non-Android projects. The BuildConfig logic is something I thought of when @adesrosiers raised this issue, but wouldn't work for non-Android projects.

Potentially I could create an Android-specific package to provide version number support.

[Stuie]

I added support for self-managed milestones in version 0.0.3. I still need to investigate an Android-specific solution. I'm not entirely sure that the BuildConfig class is available at the point the annotationProcessor gets run, so it's not a trivial matter.

A gradle plugin may be worth looking into.

[Stuie]

Gradle supports annotationProcessorOptions, which allows you to pass arguments from your build.gradle to the annotationProcessor. The information I've found seems to talk about the JACK build chain for Android projects, which not everyone will have moved to by now.

I'm going to be away for a week, so I'm leaving this note for myself as a reminder of what I should look at when I return.

javaCompileOptions {
    annotationProcessorOptions {
        arguments = ['versionCode' : 'YOUR_VERSION_HERE']
    }
}

The GreenRobot EventBus supports such options.

[Stuie]

I got bored on my flight, so I had a quick go at implementing version code support. I've published 0.0.4-SNAPSHOT to the snapshot repository. The code is also available here on Github in the version-code branch.

If you're using this library in an Android project then you'll have to add the javaCompileOptions and annotationProcessorOptions sections to your build.gradle file, if you haven't already, in the defaultConfig section, as below:

android {
    defaultConfig {
        javaCompileOptions {
            annotationProcessorOptions {
                arguments = ["versionCode" : "YOUR_VERSION_CODE_HERE"]
            }
        }
    }
}

Support for versionName is a bit more complicated. Some people use semantic versioning (e.g. 3.0.1), which shouldn't be too complicated, but people also use codenames, etc. which makes it very difficult to tell if a specific version is newer or older than another. @Milestones are better suited for that.

[Stuie]

Just pushed version 0.0.4 with support for versionCode and versionName in the @RemoveThis and @Refactor annotations.

For Android projects you need to follow the instructions in the README. They're similar to my previous update on this issue, but I'll include a more complete version below for the sake of completeness.

android {
    defaultConfig {
        versionCode 4
        versionName "0.4.0"
        javaCompileOptions {
            annotationProcessorOptions {
                arguments = ['versionCode': String.valueOf(defaultConfig.versionCode),
                             'versionName': defaultConfig.versionName]
            }
        }
    }
}

You have to have a versionCode that can be parsed to an Integer, and the versionName has to adhere to the semantic versioning schema. This may not match up with what Android defaults to.

If there are problems then I may look to support other versioning schemas, but that complicates things a bit more than I'd like.