You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@@ -16,6 +16,8 @@ Our Optimizely X Android solution allows you to easily run experiments anywhere
16
16
17
17
To find out more check out the [documentation](https://developers.optimizely.com/x/solutions/sdks/introduction/index.html?language=android&platform=mobile).
18
18
19
+
This repo depends on [Optimizely X Java](https://github.com/optimizely/java-sdk).
20
+
19
21
## Architecture
20
22
21
23
This project has 5 modules. Each module has source in `<module>/src/main/java`
@@ -78,13 +80,18 @@ Tests can be run by right clicking the file in the project pane or by clicking t
78
80
79
81
## Releasing
80
82
81
-
The default branch is devel. Feature branch PRs are automatically made against it. When PRs are reviewed and pass checks they should be squashed and merged into devel. The version of the SDK in devel should always be the version of the next release plus `-SNAPSHOT`.
83
+
The default branch is devel. Feature branch PRs are automatically made against it. When PRs are reviewed and pass checks they should be squashed and merged into devel. Devel will be built and tested for each commit.
82
84
83
-
If a beta, or snapshot, build needs to be published simply checkout beta and merge devel. The beta branch should fast forward. Push devel and Travis will start. If the tests pass the build will be sent to our Maven repos on Bintray.
85
+
Versions are managed via git tags. Tags can be created from the command line or from the Github UI.
84
86
85
-
When a release version needs to be published checkout the master branch and merge devel. The master branch should be fast forwarded. Remove the `-SNAPSHOT` from the version in `build.gradle` and commit directly onto master. Push master and if the tests pass Travis will publish the version to our Maven repos on Bintray. if the version already exists on Bintray the upload will be rejected. The commit that updates the version should also be tagged with the version number.
87
+
Snapshot builds are made off of the beta branch. Travis will test all commits to this branch. When commit is tagged and pushed travis will build, test, *and*, ship the build bintray. The version name used
88
+
is the name of the tag. For snapshot builds the version should have `-SNAPSHOT` appended. For example `0.1.2-SNAPSHOT`. Multiple builds with the same version can be pushed to Bintray when using snapshot versions.
89
+
This keeps the version number from increasing too quickly for beta builds. Grade and maven ensure that users are on the latest snapshot via timestamps.
90
+
There can be only one git tag per version name so snapshot tags may need to be moved. For example `git tag -f -a 0.1.2` and `git push -f --tags`.
86
91
87
-
Once the next release has been published from the master branch the snapshot version in devel should be bumped to the next targeted version.
92
+
Release builds are made off of the master branch. Travis will test all commits to this branch. Just like the beta branch, pushing a tag will trigger a build, tests, and release of the version of the tag to Bintray.
93
+
For example, to release version 0.1.2 you need to pull devel, checkout master, pull master, fast-forward master to devel, push master, then release 0.1.2 on Github, which creates a tag. You could also run
94
+
`git tag -a 0.1.2 -m 'Version 0.1.2`. The argument to `-a` is the actual version name used on Bintray so it must be exact. Then run `git push --tags` to trigger Travis.
88
95
89
96
*Note:* only Optimizely employees can push to master, beta, and devel branches.
0 commit comments