https://github.com/codeandtheory/yanalytics-firebase-flutter
Y—Analytics implementation for Firebase SDK
https://github.com/codeandtheory/yanalytics-firebase-flutter
Last synced: 2 months ago
JSON representation
Y—Analytics implementation for Firebase SDK
- Host: GitHub
- URL: https://github.com/codeandtheory/yanalytics-firebase-flutter
- Owner: codeandtheory
- License: apache-2.0
- Created: 2023-04-19T21:16:25.000Z (almost 3 years ago)
- Default Branch: main
- Last Pushed: 2023-05-08T17:07:29.000Z (almost 3 years ago)
- Last Synced: 2025-03-08T17:02:42.917Z (12 months ago)
- Language: Dart
- Size: 279 KB
- Stars: 0
- Watchers: 3
- Forks: 0
- Open Issues: 0
-
Metadata Files:
- Readme: README.md
- Changelog: CHANGELOG.md
- License: LICENSE
- Codeowners: CODEOWNERS.txt
Awesome Lists containing this project
README
Licensing
----------
Y—Analytics Firebase is licensed under the [Apache 2.0 license](LICENSE).
Documentation
----------
Documentation is automatically generated from source code comments and rendered as a static website hosted via [GitHub Pages](https://yml-org.github.io/yanalytics-firebase-flutter/)
and [pub.dev](https://pub.dev/packages/yanalytics-firebase)
Contributing to Y-analytics
----------
### Install dependencies
```
dart pub get
```
### Generate documentation
```
# Install dartdoc
dart pub global activate dartdoc
# Run dartdoc in root directory
dartdoc --output docs
```
## Setup githooks (optional)
If you want to make sure you code is ok before running github actions configure githooks:
```
git config core.hooksPath .githooks
```
### Versioning strategy
We utilize [semantic versioning](https://semver.org).
```
{major}.{minor}.{patch}
```
e.g.
```
1.0.5
```
### Branching strategy
We utilize a simplified branching strategy for our frameworks.
* main (and development) branch is `main`
* both feature (and bugfix) branches branch off of `main`
* feature (and bugfix) branches are merged back into `main` as they are completed and approved.
* `main` gets tagged with an updated version # for each release
### Branch naming conventions:
```
feature/{ticket-number}-{short-description}
bugfix/{ticket-number}-{short-description}
```
e.g.
```
feature/CM-44-button
bugfix/CM-236-textview-color
```
### Pull Requests
Prior to submitting a pull request you should:
1. Compile and ensure there are no warnings and no errors.
2. Run all unit tests and confirm that everything passes.
3. Check unit test coverage and confirm that all new / modified code is fully covered.
4. Consider using `git rebase -i HEAD~{commit-count}` to squash your last {commit-count} commits together into functional chunks.
5. If HEAD of the parent branch (typically `main`) has been updated since you created your branch, use `git rebase main` to rebase your branch.
* _Never_ merge the parent branch into your branch.
* _Always_ rebase your branch off of the parent branch.
When submitting a pull request:
* Use the [provided pull request template](.github/pull_request_template.md) and populate the Introduction, Purpose, and Scope fields at a minimum.
* If you're submitting before and after screenshots, movies, or GIF's, enter them in a two-column table so that they can be viewed side-by-side.
When merging a pull request:
* Make sure the branch is rebased (not merged) off of the latest HEAD from the parent branch. This keeps our git history easy to read and understand.
* Make sure the branch is deleted upon merge (should be automatic).
### Releasing new versions
* Tag the corresponding commit with the new version (e.g. `1.0.5`)
* Push the local tag to remote