From c651ee62e1a7698e4efad0376aab5710655a2e2f Mon Sep 17 00:00:00 2001 From: Shahroz Khan Date: Fri, 25 Mar 2022 16:16:12 +0500 Subject: [PATCH] fix: code cleanup --- .github/pull_request_template.md | 15 +- .releaserc.json | 32 ++- CHANGELOG.md | 112 +++++++++ CODE_OF_CONDUCT.md | 129 +++++------ .../example/ExampleInstrumentedTest.kt | 2 +- app/src/main/AndroidManifest.xml | 6 +- app/src/main/res/layout/activity_main.xml | 1 + .../io/customer/example/ExampleUnitTest.kt | 2 +- .../io/customer/example/ExampleUnitTest2.kt | 2 +- buildSrc/build.gradle.kts | 2 - docs/dev-notes/GIT-WORKFLOW.md | 216 ++++++++++++------ .../messagingpush/ExampleInstrumentedTest.kt | 6 +- .../customer/messagingpush/ExampleUnitTest.kt | 3 +- .../install local.run.xml | 53 ++--- scripts/publish-root.gradle | 2 +- sdk/src/main/java/io/customer/sdk/Version.kt | 2 +- .../sdk/repository/AttributesRepository.kt | 1 - 17 files changed, 391 insertions(+), 195 deletions(-) diff --git a/.github/pull_request_template.md b/.github/pull_request_template.md index 1805924a3..ee3bdf108 100644 --- a/.github/pull_request_template.md +++ b/.github/pull_request_template.md @@ -1,5 +1,12 @@ -Complete each step to get your pull request merged in. [Learn more about the workflow this project uses](https://github.com/customerio/customerio-android/develop/docs/dev-notes/GIT-WORKFLOW.md). -- [ ] [Assign members of your team](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/requesting-a-pull-request-review) to review the pull request. -- [ ] Wait for pull request status checks to complete. If there are problems, fix them until you see that [all status checks are passing](https://external-content.duckduckgo.com/iu/?u=https%3A%2F%2Fsymfony.com%2Fdoc%2F4.3%2F_images%2Fdocs-pull-request-symfonycloud.png&f=1&nofb=1). +Complete each step to get your pull request merged +in. [Learn more about the workflow this project uses](https://github.com/customerio/customerio-android/develop/docs/dev-notes/GIT-WORKFLOW.md) +. + +- [ ] [Assign members of your team](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/requesting-a-pull-request-review) + to review the pull request. +- [ ] Wait for pull request status checks to complete. If there are problems, fix them until you see + that [all status checks are passing](https://external-content.duckduckgo.com/iu/?u=https%3A%2F%2Fsymfony.com%2Fdoc%2F4.3%2F_images%2Fdocs-pull-request-symfonycloud.png&f=1&nofb=1) + . - [ ] Wait until the pull request has been reviewed *and approved* by a teammate -- [ ] After pull request is approved, and you determine it's ready **add the label "Ready to merge"** to the pull request and it will automatically be merged. \ No newline at end of file +- [ ] After pull request is approved, and you determine it's ready **add the label "Ready to + merge"** to the pull request and it will automatically be merged. \ No newline at end of file diff --git a/.releaserc.json b/.releaserc.json index bef2e400b..14fd0c316 100644 --- a/.releaserc.json +++ b/.releaserc.json @@ -13,12 +13,18 @@ ], "dryRun": true, "plugins": [ - ["@semantic-release/commit-analyzer", { - "preset": "conventionalcommits" - }], - ["@semantic-release/release-notes-generator", { - "preset": "conventionalcommits" - }], + [ + "@semantic-release/commit-analyzer", + { + "preset": "conventionalcommits" + } + ], + [ + "@semantic-release/release-notes-generator", + { + "preset": "conventionalcommits" + } + ], [ "@semantic-release/exec", { @@ -31,10 +37,16 @@ "changelogFile": "CHANGELOG.md" } ], - ["@semantic-release/git", { - "assets": ["CHANGELOG.md", "sdk/src/main/java/io/customer/sdk/Version.kt"], - "message": "chore: prepare for ${nextRelease.version}\n\n${nextRelease.notes}" - }], + [ + "@semantic-release/git", + { + "assets": [ + "CHANGELOG.md", + "sdk/src/main/java/io/customer/sdk/Version.kt" + ], + "message": "chore: prepare for ${nextRelease.version}\n\n${nextRelease.notes}" + } + ], "@semantic-release/github" ] } \ No newline at end of file diff --git a/CHANGELOG.md b/CHANGELOG.md index a8c18304e..3e66a0850 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -1,3 +1,115 @@ +## [1.1.0-alpha.1](https://github.com/customerio/customerio-android/compare/1.0.4...1.1.0-alpha.1) (2022-03-24) + + +### Features + +* added support for device attributes ([#71](https://github.com/customerio/customerio-android/issues/71)) ([5fedf26](https://github.com/customerio/customerio-android/commit/5fedf26f251259601ab89c15b5cd691361c30e9d)) +* support for custom device attributes and config ([#77](https://github.com/customerio/customerio-android/issues/77)) ([a7dbaba](https://github.com/customerio/customerio-android/commit/a7dbaba4d82e5e7378f590425ee8b911072036a8)) + + +### Bug Fixes + +* added java compatibility in public constructors and methods ([acdec46](https://github.com/customerio/customerio-android/commit/acdec46cece2e3dc44186bc7ff3c690bf48830dc)) +* added support for big decimal ([#56](https://github.com/customerio/customerio-android/issues/56)) ([58c791b](https://github.com/customerio/customerio-android/commit/58c791b8a6c9df91506cf75064622a399ca9a8d0)) + +## [1.1.0-alpha.1](https://github.com/customerio/customerio-android/compare/1.0.4...1.1.0-alpha.1) (2022-03-24) + + +### Features + +* added support for device attributes ([#71](https://github.com/customerio/customerio-android/issues/71)) ([5fedf26](https://github.com/customerio/customerio-android/commit/5fedf26f251259601ab89c15b5cd691361c30e9d)) +* support for custom device attributes and config ([#77](https://github.com/customerio/customerio-android/issues/77)) ([a7dbaba](https://github.com/customerio/customerio-android/commit/a7dbaba4d82e5e7378f590425ee8b911072036a8)) + + +### Bug Fixes + +* added java compatibility in public constructors and methods ([acdec46](https://github.com/customerio/customerio-android/commit/acdec46cece2e3dc44186bc7ff3c690bf48830dc)) +* added support for big decimal ([#56](https://github.com/customerio/customerio-android/issues/56)) ([58c791b](https://github.com/customerio/customerio-android/commit/58c791b8a6c9df91506cf75064622a399ca9a8d0)) + +## [1.1.0-alpha.1](https://github.com/customerio/customerio-android/compare/1.0.4...1.1.0-alpha.1) (2022-03-24) + + +### Features + +* added support for device attributes ([#71](https://github.com/customerio/customerio-android/issues/71)) ([5fedf26](https://github.com/customerio/customerio-android/commit/5fedf26f251259601ab89c15b5cd691361c30e9d)) +* support for custom device attributes and config ([#77](https://github.com/customerio/customerio-android/issues/77)) ([a7dbaba](https://github.com/customerio/customerio-android/commit/a7dbaba4d82e5e7378f590425ee8b911072036a8)) + + +### Bug Fixes + +* added java compatibility in public constructors and methods ([acdec46](https://github.com/customerio/customerio-android/commit/acdec46cece2e3dc44186bc7ff3c690bf48830dc)) +* added support for big decimal ([#56](https://github.com/customerio/customerio-android/issues/56)) ([58c791b](https://github.com/customerio/customerio-android/commit/58c791b8a6c9df91506cf75064622a399ca9a8d0)) + +## [1.1.0-alpha.1](https://github.com/customerio/customerio-android/compare/1.0.4...1.1.0-alpha.1) (2022-03-24) + + +### Features + +* added support for device attributes ([#71](https://github.com/customerio/customerio-android/issues/71)) ([5fedf26](https://github.com/customerio/customerio-android/commit/5fedf26f251259601ab89c15b5cd691361c30e9d)) +* support for custom device attributes and config ([#77](https://github.com/customerio/customerio-android/issues/77)) ([a7dbaba](https://github.com/customerio/customerio-android/commit/a7dbaba4d82e5e7378f590425ee8b911072036a8)) + + +### Bug Fixes + +* added java compatibility in public constructors and methods ([acdec46](https://github.com/customerio/customerio-android/commit/acdec46cece2e3dc44186bc7ff3c690bf48830dc)) +* added support for big decimal ([#56](https://github.com/customerio/customerio-android/issues/56)) ([58c791b](https://github.com/customerio/customerio-android/commit/58c791b8a6c9df91506cf75064622a399ca9a8d0)) + +## [1.1.0-alpha.1](https://github.com/customerio/customerio-android/compare/1.0.4...1.1.0-alpha.1) (2022-03-24) + + +### Features + +* added support for device attributes ([#71](https://github.com/customerio/customerio-android/issues/71)) ([5fedf26](https://github.com/customerio/customerio-android/commit/5fedf26f251259601ab89c15b5cd691361c30e9d)) +* support for custom device attributes and config ([#77](https://github.com/customerio/customerio-android/issues/77)) ([a7dbaba](https://github.com/customerio/customerio-android/commit/a7dbaba4d82e5e7378f590425ee8b911072036a8)) + + +### Bug Fixes + +* added java compatibility in public constructors and methods ([acdec46](https://github.com/customerio/customerio-android/commit/acdec46cece2e3dc44186bc7ff3c690bf48830dc)) +* added support for big decimal ([#56](https://github.com/customerio/customerio-android/issues/56)) ([58c791b](https://github.com/customerio/customerio-android/commit/58c791b8a6c9df91506cf75064622a399ca9a8d0)) + +## [1.1.0-alpha.1](https://github.com/customerio/customerio-android/compare/1.0.4...1.1.0-alpha.1) (2022-03-24) + + +### Features + +* added support for device attributes ([#71](https://github.com/customerio/customerio-android/issues/71)) ([5fedf26](https://github.com/customerio/customerio-android/commit/5fedf26f251259601ab89c15b5cd691361c30e9d)) +* support for custom device attributes and config ([#77](https://github.com/customerio/customerio-android/issues/77)) ([a7dbaba](https://github.com/customerio/customerio-android/commit/a7dbaba4d82e5e7378f590425ee8b911072036a8)) + + +### Bug Fixes + +* added java compatibility in public constructors and methods ([acdec46](https://github.com/customerio/customerio-android/commit/acdec46cece2e3dc44186bc7ff3c690bf48830dc)) +* added support for big decimal ([#56](https://github.com/customerio/customerio-android/issues/56)) ([58c791b](https://github.com/customerio/customerio-android/commit/58c791b8a6c9df91506cf75064622a399ca9a8d0)) + +## [1.1.0-alpha.1](https://github.com/customerio/customerio-android/compare/1.0.4...1.1.0-alpha.1) (2022-03-24) + + +### Features + +* added support for device attributes ([#71](https://github.com/customerio/customerio-android/issues/71)) ([5fedf26](https://github.com/customerio/customerio-android/commit/5fedf26f251259601ab89c15b5cd691361c30e9d)) +* support for custom device attributes and config ([#77](https://github.com/customerio/customerio-android/issues/77)) ([a7dbaba](https://github.com/customerio/customerio-android/commit/a7dbaba4d82e5e7378f590425ee8b911072036a8)) + + +### Bug Fixes + +* added java compatibility in public constructors and methods ([acdec46](https://github.com/customerio/customerio-android/commit/acdec46cece2e3dc44186bc7ff3c690bf48830dc)) +* added support for big decimal ([#56](https://github.com/customerio/customerio-android/issues/56)) ([58c791b](https://github.com/customerio/customerio-android/commit/58c791b8a6c9df91506cf75064622a399ca9a8d0)) + +## [1.1.0-alpha.1](https://github.com/customerio/customerio-android/compare/1.0.4...1.1.0-alpha.1) (2022-03-24) + + +### Features + +* added support for device attributes ([#71](https://github.com/customerio/customerio-android/issues/71)) ([5fedf26](https://github.com/customerio/customerio-android/commit/5fedf26f251259601ab89c15b5cd691361c30e9d)) +* support for custom device attributes and config ([#77](https://github.com/customerio/customerio-android/issues/77)) ([a7dbaba](https://github.com/customerio/customerio-android/commit/a7dbaba4d82e5e7378f590425ee8b911072036a8)) + + +### Bug Fixes + +* added java compatibility in public constructors and methods ([acdec46](https://github.com/customerio/customerio-android/commit/acdec46cece2e3dc44186bc7ff3c690bf48830dc)) +* added support for big decimal ([#56](https://github.com/customerio/customerio-android/issues/56)) ([58c791b](https://github.com/customerio/customerio-android/commit/58c791b8a6c9df91506cf75064622a399ca9a8d0)) + ## [1.0.4](https://github.com/customerio/customerio-android/compare/1.0.3...1.0.4) (2022-03-21) diff --git a/CODE_OF_CONDUCT.md b/CODE_OF_CONDUCT.md index 37181b7e5..a6c7ea9c9 100644 --- a/CODE_OF_CONDUCT.md +++ b/CODE_OF_CONDUCT.md @@ -1,133 +1,122 @@ - # Contributor Covenant Code of Conduct ## Our Pledge -We as members, contributors, and leaders pledge to make participation in our -community a harassment-free experience for everyone, regardless of age, body -size, visible or invisible disability, ethnicity, sex characteristics, gender -identity and expression, level of experience, education, socio-economic status, -nationality, personal appearance, race, caste, color, religion, or sexual identity -and orientation. +We as members, contributors, and leaders pledge to make participation in our community a +harassment-free experience for everyone, regardless of age, body size, visible or invisible +disability, ethnicity, sex characteristics, gender identity and expression, level of experience, +education, socio-economic status, nationality, personal appearance, race, caste, color, religion, or +sexual identity and orientation. -We pledge to act and interact in ways that contribute to an open, welcoming, -diverse, inclusive, and healthy community. +We pledge to act and interact in ways that contribute to an open, welcoming, diverse, inclusive, and +healthy community. ## Our Standards -Examples of behavior that contributes to a positive environment for our -community include: +Examples of behavior that contributes to a positive environment for our community include: * Demonstrating empathy and kindness toward other people * Being respectful of differing opinions, viewpoints, and experiences * Giving and gracefully accepting constructive feedback -* Accepting responsibility and apologizing to those affected by our mistakes, - and learning from the experience -* Focusing on what is best not just for us as individuals, but for the - overall community +* Accepting responsibility and apologizing to those affected by our mistakes, and learning from the + experience +* Focusing on what is best not just for us as individuals, but for the overall community Examples of unacceptable behavior include: -* The use of sexualized language or imagery, and sexual attention or - advances of any kind +* The use of sexualized language or imagery, and sexual attention or advances of any kind * Trolling, insulting or derogatory comments, and personal or political attacks * Public or private harassment -* Publishing others' private information, such as a physical or email - address, without their explicit permission -* Other conduct which could reasonably be considered inappropriate in a - professional setting +* Publishing others' private information, such as a physical or email address, without their + explicit permission +* Other conduct which could reasonably be considered inappropriate in a professional setting ## Enforcement Responsibilities -Community leaders are responsible for clarifying and enforcing our standards of -acceptable behavior and will take appropriate and fair corrective action in -response to any behavior that they deem inappropriate, threatening, offensive, -or harmful. +Community leaders are responsible for clarifying and enforcing our standards of acceptable behavior +and will take appropriate and fair corrective action in response to any behavior that they deem +inappropriate, threatening, offensive, or harmful. -Community leaders have the right and responsibility to remove, edit, or reject -comments, commits, code, wiki edits, issues, and other contributions that are -not aligned to this Code of Conduct, and will communicate reasons for moderation -decisions when appropriate. +Community leaders have the right and responsibility to remove, edit, or reject comments, commits, +code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, and +will communicate reasons for moderation decisions when appropriate. ## Scope -This Code of Conduct applies within all community spaces, and also applies when -an individual is officially representing the community in public spaces. -Examples of representing our community include using an official e-mail address, -posting via an official social media account, or acting as an appointed -representative at an online or offline event. +This Code of Conduct applies within all community spaces, and also applies when an individual is +officially representing the community in public spaces. Examples of representing our community +include using an official e-mail address, posting via an official social media account, or acting as +an appointed representative at an online or offline event. ## Enforcement -Instances of abusive, harassing, or otherwise unacceptable behavior may be -reported to the community leaders responsible for enforcement at `win@customer.io`. -All complaints will be reviewed and investigated promptly and fairly. +Instances of abusive, harassing, or otherwise unacceptable behavior may be reported to the community +leaders responsible for enforcement at `win@customer.io`. All complaints will be reviewed and +investigated promptly and fairly. -All community leaders are obligated to respect the privacy and security of the -reporter of any incident. +All community leaders are obligated to respect the privacy and security of the reporter of any +incident. ## Enforcement Guidelines -Community leaders will follow these Community Impact Guidelines in determining -the consequences for any action they deem in violation of this Code of Conduct: +Community leaders will follow these Community Impact Guidelines in determining the consequences for +any action they deem in violation of this Code of Conduct: ### 1. Correction -**Community Impact**: Use of inappropriate language or other behavior deemed -unprofessional or unwelcome in the community. +**Community Impact**: Use of inappropriate language or other behavior deemed unprofessional or +unwelcome in the community. -**Consequence**: A private, written warning from community leaders, providing -clarity around the nature of the violation and an explanation of why the -behavior was inappropriate. A public apology may be requested. +**Consequence**: A private, written warning from community leaders, providing clarity around the +nature of the violation and an explanation of why the behavior was inappropriate. A public apology +may be requested. ### 2. Warning -**Community Impact**: A violation through a single incident or series -of actions. +**Community Impact**: A violation through a single incident or series of actions. -**Consequence**: A warning with consequences for continued behavior. No -interaction with the people involved, including unsolicited interaction with -those enforcing the Code of Conduct, for a specified period of time. This -includes avoiding interactions in community spaces as well as external channels -like social media. Violating these terms may lead to a temporary or -permanent ban. +**Consequence**: A warning with consequences for continued behavior. No interaction with the people +involved, including unsolicited interaction with those enforcing the Code of Conduct, for a +specified period of time. This includes avoiding interactions in community spaces as well as +external channels like social media. Violating these terms may lead to a temporary or permanent ban. ### 3. Temporary Ban -**Community Impact**: A serious violation of community standards, including -sustained inappropriate behavior. +**Community Impact**: A serious violation of community standards, including sustained inappropriate +behavior. -**Consequence**: A temporary ban from any sort of interaction or public -communication with the community for a specified period of time. No public or -private interaction with the people involved, including unsolicited interaction -with those enforcing the Code of Conduct, is allowed during this period. -Violating these terms may lead to a permanent ban. +**Consequence**: A temporary ban from any sort of interaction or public communication with the +community for a specified period of time. No public or private interaction with the people involved, +including unsolicited interaction with those enforcing the Code of Conduct, is allowed during this +period. Violating these terms may lead to a permanent ban. ### 4. Permanent Ban -**Community Impact**: Demonstrating a pattern of violation of community -standards, including sustained inappropriate behavior, harassment of an -individual, or aggression toward or disparagement of classes of individuals. +**Community Impact**: Demonstrating a pattern of violation of community standards, including +sustained inappropriate behavior, harassment of an individual, or aggression toward or disparagement +of classes of individuals. -**Consequence**: A permanent ban from any sort of public interaction within -the community. +**Consequence**: A permanent ban from any sort of public interaction within the community. ## Attribution -This Code of Conduct is adapted from the [Contributor Covenant][homepage], -version 2.0, available at +This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 2.0, available at [https://www.contributor-covenant.org/version/2/0/code_of_conduct.html][v2.0]. -Community Impact Guidelines were inspired by +Community Impact Guidelines were inspired by [Mozilla's code of conduct enforcement ladder][Mozilla CoC]. For answers to common questions about this code of conduct, see the FAQ at -[https://www.contributor-covenant.org/faq][FAQ]. Translations are available +[https://www.contributor-covenant.org/faq][FAQ]. Translations are available at [https://www.contributor-covenant.org/translations][translations]. [homepage]: https://www.contributor-covenant.org + [v2.0]: https://www.contributor-covenant.org/version/2/0/code_of_conduct.html + [Mozilla CoC]: https://github.com/mozilla/diversity + [FAQ]: https://www.contributor-covenant.org/faq + [translations]: https://www.contributor-covenant.org/translations diff --git a/app/src/androidTest/java/io/customer/example/ExampleInstrumentedTest.kt b/app/src/androidTest/java/io/customer/example/ExampleInstrumentedTest.kt index bba390263..55918e33d 100644 --- a/app/src/androidTest/java/io/customer/example/ExampleInstrumentedTest.kt +++ b/app/src/androidTest/java/io/customer/example/ExampleInstrumentedTest.kt @@ -2,7 +2,7 @@ package io.customer.example import androidx.test.ext.junit.runners.AndroidJUnit4 import androidx.test.platform.app.InstrumentationRegistry -import org.junit.Assert.* +import org.junit.Assert.assertEquals import org.junit.Test import org.junit.runner.RunWith diff --git a/app/src/main/AndroidManifest.xml b/app/src/main/AndroidManifest.xml index d19b94d0d..1afdd5cc2 100644 --- a/app/src/main/AndroidManifest.xml +++ b/app/src/main/AndroidManifest.xml @@ -8,17 +8,17 @@ + android:exported="true" + android:label="Home"> diff --git a/app/src/main/res/layout/activity_main.xml b/app/src/main/res/layout/activity_main.xml index 2cdc91823..a1a0adb4e 100644 --- a/app/src/main/res/layout/activity_main.xml +++ b/app/src/main/res/layout/activity_main.xml @@ -5,6 +5,7 @@ android:layout_width="match_parent" android:layout_height="match_parent" tools:context=".MainActivity"> + Tip: If you have read this document already, you may want to [skip straight to the scenarios section](#Scenarios). +> Tip: If you have read this document already, you may want to [skip straight to the scenarios section](#Scenarios). -# About the workflow +# About the workflow -This project follows [this popular workflow called `git-flow`](https://nvie.com/posts/a-successful-git-branching-model/). `git-flow` works well for this project because this project releases different versions of `alpha`, `beta`, and `production` versions of software to the public. Go ahead and [read over the `git-flow`](https://nvie.com/posts/a-successful-git-branching-model/) workflow to learn about the details of it. +This project +follows [this popular workflow called `git-flow`](https://nvie.com/posts/a-successful-git-branching-model/) +. `git-flow` works well for this project because this project releases different versions of `alpha` +, `beta`, and `production` versions of software to the public. Go ahead +and [read over the `git-flow`](https://nvie.com/posts/a-successful-git-branching-model/) workflow to +learn about the details of it. -The [article you just read](https://nvie.com/posts/a-successful-git-branching-model/) shows you how you can manually run `git` commands on a repository to merge in new features, fix bugs, and make deployments. Our team might need to perform some manual tasks, but we try to automate running these `git` commands as much as possible. Automating these tasks helps to (1) avoid human error and (2) allows you to focus on simply writing code and avoid having to learn how to deploy the code. We try to keep this workflow as simple as possible by automating much of it. However, **if out automated tools ever encounter a problem and you need to manually fix the problem yourself, read the `git-flow` article to learn what `git` commands you need to run to fix the problem manually.** +The [article you just read](https://nvie.com/posts/a-successful-git-branching-model/) shows you how +you can manually run `git` commands on a repository to merge in new features, fix bugs, and make +deployments. Our team might need to perform some manual tasks, but we try to automate running +these `git` commands as much as possible. Automating these tasks helps to (1) avoid human error +and (2) allows you to focus on simply writing code and avoid having to learn how to deploy the code. +We try to keep this workflow as simple as possible by automating much of it. However, **if out +automated tools ever encounter a problem and you need to manually fix the problem yourself, read +the `git-flow` article to learn what `git` commands you need to run to fix the problem manually.** -Let's get into the many scenarios that you may encounter when working on this project and how you could do those tasks. +Let's get into the many scenarios that you may encounter when working on this project and how you +could do those tasks. -## Deployment flow +## Deployment flow -To understand this workflow, you need to understand how code is deployed. +To understand this workflow, you need to understand how code is deployed. To help describe the deployment flow, refer to this image from the `git-flow` article: ![](https://nvie.com/img/git-model@2x.png) -There is a lot going on with this image. Let's try and explain it a little bit. -* **2 permanent branches** - The branches `main` and `develop` are permanent branches and they never get deleted. `main` gets updated when a production deployment is made. `develop` is the default branch that code gets merged into that will be made into the next release of the software. -* **Feature branches, bug fix branches, pre-release branches, etc** - All other branches (not `main` or `develop`) are temporary and get deleted after they have served their purpose. -* **Make pull requests for all changes that you make to the project** - Any change that you make to the project should be merged into the project via a pull request on GitHub. That means that you should not be making commits to the branches: `develop`, `alpha`, `beta`, or `main`. - -* The *pink dots* on the left hand side are new features that you or your teammates are working on. You start a new feature by making a new branch off of the `develop` branch (or another feature branch if you need some code from that branch). It's important that new feature branches *do not* get created from release branches such as `alpha`, `beta`, or `main`. It's also important that new feature branches get merged into the `develop` branch, only. If your team made an `alpha` or `beta` release of your software yesterday and your new feature gets merged into `develop` today, your new feature should not get released until the current `alpha` or `beta` gets merged into production and then a new release is made in the future. -* The *yellow dots* are commits on the develop branch. All pull requests and releases will eventually get merged into the `develop` branch. -* The *green dots* are for a new release. Your team merged code into `main` last week which means that you made a production deployment on that day. Today, your team decides that the new code added to the `develop` branch should be released to the public. Maybe you added a new feature that you are wanting to ship. To start this release, you make a **pre-release** branch. On this team, that means that we make a new branch `alpha` off of the `develop` branch. Making this `alpha` branch will deploy a new alpha deployment of our software. - -When our team decides that it's time to promote the latest alpha release of our software to beta, a new branch `beta` is made off of the `alpha` branch and then the `alpha` branch gets deleted (remember, all branches except `main` and `develop` are temporary). When `beta` branch is made, a beta deployment gets deployed. - -> Note: Once a release has been started (when `alpha` or `beta` branch is created), only bug fixes should be merged into the release until it's in production. If you find a bug on the `alpha` or `beta` release, then you will make a new branch off of the `alpha` or `beta` branch and make a pull request with that fix back into `alpha` or `beta` branch. - -* The *red dots* are hotfix branches. Let's say that a customer finds a critical bug in one of our production releases. Our team may decide that we need to get this bug fixed as soon as possible and we decide to skip releasing this bug fix to `alpha` and `beta` and we deploy the bug fix immediately to production (after QA testing). To do that, you should make a new branch off of `main` (aka the latest production code), fix the bug, then make a pull request into `main`. When the pull request gets merged, there will be a new production deployment in production. - -* Finally *the blue dots* are git tags. Git tags [are all deployments][url-tags] that you have made for your software. When any release is made, a git tag gets made. - -With all of that explained, lets go over some common scenarios that you will encounter while working on this project. In fact, it might be a good idea to [click this link](#Scenarios) and then bookmark it in your browser so it's convenient. - -# Scenarios - -## Build a new feature - -Want to build a new feature? Here is how you would do that. -1. Create a new branch for your feature. We like to name our branches `/`. For example, if my name is Dana and I was to add a feature to allow customers to edit their photo on their profile, I would create a new branch `dana/edit-picture-profile`. Make this new branch off of the `develop` branch. -2. Let's say that another member of your team, Bradley, is building a feature that allows users to upload photos in the app. You need that feature in your new feature you're working on for editing profile pictures. If you need this code, simply `git merge bradley/upload-photos` into your feature branch that you made. -3. When you're done making this feature, make a pull request merging your branch *into the `develop` branch*. Features should *not* be merged into a release branch (`alpha`, `beta`, `main`). Your feature will be released to the public the next time that your team makes a release. - -## Fix a bug - -Where did you find this bug? -* **In an `alpha` or `beta` release** of the software (the version of the release ends with `-alpha.X` or `-beta.X` such as `1.0.0-alpha.1`)? -If so, make a new git branch off of the `alpha` or `beta` branch, fix the bug, then make a pull request merging your pull request into the `alpha` or `beta` branch. - -* **In a production release** of the software (the version of the release does *not* end with `-alpha.X` or `-beta.X` such as `1.0.0`)? -If so, make a new git branch off of the `main` branch, fix the bug, then make a pull request merging your pull request into the `main` branch. After the pull request gets merged, a new production release will be made to customers. - -> Note: When making a bug fix pull request, it's preferred that you include an automated test (unit test function, integration test, etc) in this pull request that reproduces the bug. This is to help us feel confident the bug is indeed fixed and it will not come up again in the future. - -## Make a new release - -### Want to make a new release of the project to Alpha? -(Your project does *not* have a `alpha` or `beta` branch already and you want to make a new Alpha from the `develop` branch) +There is a lot going on with this image. Let's try and explain it a little bit. + +* **2 permanent branches** - The branches `main` and `develop` are permanent branches and they never + get deleted. `main` gets updated when a production deployment is made. `develop` is the default + branch that code gets merged into that will be made into the next release of the software. +* **Feature branches, bug fix branches, pre-release branches, etc** - All other branches (not `main` + or `develop`) are temporary and get deleted after they have served their purpose. +* **Make pull requests for all changes that you make to the project** - Any change that you make to + the project should be merged into the project via a pull request on GitHub. That means that you + should not be making commits to the branches: `develop`, `alpha`, `beta`, or `main`. + +* The *pink dots* on the left hand side are new features that you or your teammates are working on. + You start a new feature by making a new branch off of the `develop` branch (or another feature + branch if you need some code from that branch). It's important that new feature branches *do not* + get created from release branches such as `alpha`, `beta`, or `main`. It's also important that new + feature branches get merged into the `develop` branch, only. If your team made an `alpha` + or `beta` release of your software yesterday and your new feature gets merged into `develop` + today, your new feature should not get released until the current `alpha` or `beta` gets merged + into production and then a new release is made in the future. +* The *yellow dots* are commits on the develop branch. All pull requests and releases will + eventually get merged into the `develop` branch. +* The *green dots* are for a new release. Your team merged code into `main` last week which means + that you made a production deployment on that day. Today, your team decides that the new code + added to the `develop` branch should be released to the public. Maybe you added a new feature that + you are wanting to ship. To start this release, you make a **pre-release** branch. On this team, + that means that we make a new branch `alpha` off of the `develop` branch. Making this `alpha` + branch will deploy a new alpha deployment of our software. + +When our team decides that it's time to promote the latest alpha release of our software to beta, a +new branch `beta` is made off of the `alpha` branch and then the `alpha` branch gets deleted ( +remember, all branches except `main` and `develop` are temporary). When `beta` branch is made, a +beta deployment gets deployed. + +> Note: Once a release has been started (when `alpha` or `beta` branch is created), only bug fixes should be merged into the release until it's in production. If you find a bug on the `alpha` or `beta` release, then you will make a new branch off of the `alpha` or `beta` branch and make a pull request with that fix back into `alpha` or `beta` branch. + +* The *red dots* are hotfix branches. Let's say that a customer finds a critical bug in one of our + production releases. Our team may decide that we need to get this bug fixed as soon as possible + and we decide to skip releasing this bug fix to `alpha` and `beta` and we deploy the bug fix + immediately to production (after QA testing). To do that, you should make a new branch off + of `main` (aka the latest production code), fix the bug, then make a pull request into `main`. + When the pull request gets merged, there will be a new production deployment in production. + +* Finally *the blue dots* are git tags. Git tags [are all deployments][url-tags] that you have made + for your software. When any release is made, a git tag gets made. + +With all of that explained, lets go over some common scenarios that you will encounter while working +on this project. In fact, it might be a good idea to [click this link](#Scenarios) and then bookmark +it in your browser so it's convenient. + +# Scenarios + +## Build a new feature + +Want to build a new feature? Here is how you would do that. + +1. Create a new branch for your feature. We like to name our + branches `/`. For example, if my name is Dana and I was to add a + feature to allow customers to edit their photo on their profile, I would create a new + branch `dana/edit-picture-profile`. Make this new branch off of the `develop` branch. +2. Let's say that another member of your team, Bradley, is building a feature that allows users to + upload photos in the app. You need that feature in your new feature you're working on for editing + profile pictures. If you need this code, simply `git merge bradley/upload-photos` into your + feature branch that you made. +3. When you're done making this feature, make a pull request merging your branch *into the `develop` + branch*. Features should *not* be merged into a release branch (`alpha`, `beta`, `main`). Your + feature will be released to the public the next time that your team makes a release. + +## Fix a bug + +Where did you find this bug? + +* **In an `alpha` or `beta` release** of the software (the version of the release ends + with `-alpha.X` or `-beta.X` such as `1.0.0-alpha.1`)? If so, make a new git branch off of + the `alpha` or `beta` branch, fix the bug, then make a pull request merging your pull request into + the `alpha` or `beta` branch. + +* **In a production release** of the software (the version of the release does *not* end + with `-alpha.X` or `-beta.X` such as `1.0.0`)? If so, make a new git branch off of the `main` + branch, fix the bug, then make a pull request merging your pull request into the `main` branch. + After the pull request gets merged, a new production release will be made to customers. + +> Note: When making a bug fix pull request, it's preferred that you include an automated test (unit test function, integration test, etc) in this pull request that reproduces the bug. This is to help us feel confident the bug is indeed fixed and it will not come up again in the future. + +## Make a new release + +### Want to make a new release of the project to Alpha? + +(Your project does *not* have a `alpha` or `beta` branch already and you want to make a new Alpha +from the `develop` branch) Follow these steps to promote using the recommended automated method: -* [Click this link][url-promote-action] > Run workflow > For "Use workflow from", select `develop` > Run. + +* [Click this link][url-promote-action] > Run workflow > For "Use workflow from", select `develop` > + Run.
Did you encounter a problem with the automated release and you need to manually promote? Follow these steps: @@ -84,14 +147,18 @@ git checkout -b alpha git push origin alpha ``` -* Tell the team that you encountered an issue with making an automated release so it can be fixed. +* Tell the team that you encountered an issue with making an automated release so it can be fixed. +
-### Want to promote the latest alpha to beta? +### Want to promote the latest alpha to beta? + (There is an `alpha` branch in the project already that you want to promote to beta) Follow these steps to promote using the recommended automated method: -* [Click this link][url-promote-action] > Run workflow > For "Use workflow from", select `alpha` > Run. + +* [Click this link][url-promote-action] > Run workflow > For "Use workflow from", select `alpha` > + Run.
Did you encounter a problem with the automated release and you need to manually promote? Follow these steps: @@ -110,14 +177,19 @@ git push origin beta git push origin --delete alpha ``` -* Tell the team that you encountered an issue with making an automated release so it can be fixed. +* Tell the team that you encountered an issue with making an automated release so it can be fixed. +
-### Want to promote the latest beta to production?** -(Do you already have a beta released out to customers (there is an `beta` branch in the project already) that you want to promote to production) +### Want to promote the latest beta to production?** + +(Do you already have a beta released out to customers (there is an `beta` branch in the project +already) that you want to promote to production) Follow these steps to promote using the recommended automated method: -* [Click this link][url-promote-action] > Run workflow > For "Use workflow from", select `beta` > Run. + +* [Click this link][url-promote-action] > Run workflow > For "Use workflow from", select `beta` > + Run.
Did you encounter a problem with the automated release and you need to manually promote? Follow these steps: @@ -144,16 +216,24 @@ git merge main git push origin develop ``` -* Tell the team that you encountered an issue with making an automated release so it can be fixed. +* Tell the team that you encountered an issue with making an automated release so it can be fixed. +
-### Want to promote `develop` directly to Beta and skip Alpha? -(Project does *not* contain `alpha` or `beta` branch already and you want to make a new Beta from the `develop` branch) +### Want to promote `develop` directly to Beta and skip Alpha? + +(Project does *not* contain `alpha` or `beta` branch already and you want to make a new Beta from +the `develop` branch) -What is the use case for why you want to skip making an Alpha release and go straight to Beta? +What is the use case for why you want to skip making an Alpha release and go straight to Beta? -* Is it because you found a bug in production and you want to quickly release a fix? Follow the steps in [Fix a bug](#Fix-a-bug). -* Is it because the project already has an Alpha released that you want to promote to Beta? Follow the steps in [Want to promote the latest alpha to beta?](#Want-to-promote-the-latest-alpha-to-beta) -* Any other reason? This is more then likely a red flag in a situation that we do not recommend that you do. You should probably follow the steps to make a new Alpha release from `develop`. -Bring up to your team your use case for why you want to do this to see if it's a scenario that we should automate. +* Is it because you found a bug in production and you want to quickly release a fix? Follow the + steps in [Fix a bug](#Fix-a-bug). +* Is it because the project already has an Alpha released that you want to promote to Beta? Follow + the steps + in [Want to promote the latest alpha to beta?](#Want-to-promote-the-latest-alpha-to-beta) +* Any other reason? This is more then likely a red flag in a situation that we do not recommend that + you do. You should probably follow the steps to make a new Alpha release from `develop`. Bring up + to your team your use case for why you want to do this to see if it's a scenario that we should + automate. diff --git a/messagingpush/src/androidTest/java/io/customer/messagingpush/ExampleInstrumentedTest.kt b/messagingpush/src/androidTest/java/io/customer/messagingpush/ExampleInstrumentedTest.kt index 9a3f6b99a..17413eae7 100644 --- a/messagingpush/src/androidTest/java/io/customer/messagingpush/ExampleInstrumentedTest.kt +++ b/messagingpush/src/androidTest/java/io/customer/messagingpush/ExampleInstrumentedTest.kt @@ -1,13 +1,11 @@ package io.customer.messagingpush -import androidx.test.platform.app.InstrumentationRegistry import androidx.test.ext.junit.runners.AndroidJUnit4 - +import androidx.test.platform.app.InstrumentationRegistry +import org.junit.Assert.assertEquals import org.junit.Test import org.junit.runner.RunWith -import org.junit.Assert.* - /** * Instrumented test, which will execute on an Android device. * diff --git a/messagingpush/src/test/java/io/customer/messagingpush/ExampleUnitTest.kt b/messagingpush/src/test/java/io/customer/messagingpush/ExampleUnitTest.kt index b7553f809..5858c72ec 100644 --- a/messagingpush/src/test/java/io/customer/messagingpush/ExampleUnitTest.kt +++ b/messagingpush/src/test/java/io/customer/messagingpush/ExampleUnitTest.kt @@ -1,9 +1,8 @@ package io.customer.messagingpush +import org.junit.Assert.assertEquals import org.junit.Test -import org.junit.Assert.* - /** * Example local unit test, which will execute on the development machine (host). * diff --git a/scripts/androidStudioRunConfigurations/install local.run.xml b/scripts/androidStudioRunConfigurations/install local.run.xml index 543fad98b..ae891aad0 100644 --- a/scripts/androidStudioRunConfigurations/install local.run.xml +++ b/scripts/androidStudioRunConfigurations/install local.run.xml @@ -1,28 +1,29 @@ - - - - - - - true - true - false - - + + + + + + + true + true + false + + \ No newline at end of file diff --git a/scripts/publish-root.gradle b/scripts/publish-root.gradle index 03d3d9daa..bde336015 100644 --- a/scripts/publish-root.gradle +++ b/scripts/publish-root.gradle @@ -18,7 +18,7 @@ if (secretPropsFile.exists()) { Properties p = new Properties() new FileInputStream(secretPropsFile).withCloseable { is -> p.load(is) } p.each { name, value -> ext[name] = value } -} +} // Set up Sonatype repository nexusPublishing { diff --git a/sdk/src/main/java/io/customer/sdk/Version.kt b/sdk/src/main/java/io/customer/sdk/Version.kt index 4bfa31b46..3fed6fdd5 100644 --- a/sdk/src/main/java/io/customer/sdk/Version.kt +++ b/sdk/src/main/java/io/customer/sdk/Version.kt @@ -7,5 +7,5 @@ package io.customer.sdk internal object Version { - const val version: String = "1.0.4" + const val version: String = "1.1.0-alpha.1" } diff --git a/sdk/src/main/java/io/customer/sdk/repository/AttributesRepository.kt b/sdk/src/main/java/io/customer/sdk/repository/AttributesRepository.kt index d773d1db5..740f41b26 100644 --- a/sdk/src/main/java/io/customer/sdk/repository/AttributesRepository.kt +++ b/sdk/src/main/java/io/customer/sdk/repository/AttributesRepository.kt @@ -3,7 +3,6 @@ package io.customer.sdk.repository import io.customer.base.extenstions.getUnixTimestamp import io.customer.sdk.data.moshi.CustomerIOParser import java.util.* -import kotlin.collections.HashMap internal interface AttributesRepository { fun mapToJson(map: Map): Map