Split into README, DEVELOPING, RELEASING files

This commit is contained in:
Caleb Jasik 2025-03-27 16:37:15 -05:00
parent 379b997c05
commit ad9b331f32
No known key found for this signature in database
3 changed files with 18 additions and 18 deletions

View file

@ -2,7 +2,7 @@
## Setting up dev environment
Install all of the following things:
Install all the following things:
- [`xcode`](https://apps.apple.com/us/app/xcode/) - use the version specified by `xcode_select` in `/ios/fastlane/Fastfile`
- [`android-studio`](https://developer.android.com/studio)
@ -28,7 +28,7 @@ Run `flutter doctor` and fix everything it complains before proceeding
If you are having issues with iOS pods, try blowing it all away! `cd ios && rm -rf Pods/ Podfile.lock && pod install --repo-update`
# Formatting
## Formatting
`dart format` can be used to format the code in `lib` and `test`. We use a line-length of 120 characters.
@ -39,17 +39,3 @@ dart format lib/ test/ -l 120
In Android Studio, set the line length using Preferences → Editor → Code Style → Dart → Line length, set it to 120. Enable auto-format with Preferences → Languages & Frameworks → Flutter → Format code on save.
# Prerelease
Push a git tag `v#.#.#-##`, e.g. `v0.5.1-0`, and `.github/release.yml` will build a draft release and publish it to iOS TestFlight and Android internal track.
`./swift-format.sh` can be used to format Swift code in the repo.
Once `swift-format` supports ignoring directories (<https://github.com/swiftlang/swift-format/issues/870>), we can move to a method of running it more like what <https://calebhearth.com/swift-format-github-action> describes.
# Release
1. Manually promote a prerelease build from TestFlight and Android internal track to the corresponding public app stores.
2. Mark the associated draft release as published, removing the `-##` from it, ending with a release in the format `v#.#.#`, e.g. `v0.5.1`.
3. Remove the old draft releases that will never be published.
4. Add the notable changes to the app to the release summary, e.g.: <https://github.com/DefinedNet/mobile_nebula/releases/tag/v0.5.1>.

View file

@ -7,5 +7,3 @@ Nebula is an overlay networking tool designed to be fast, secure, and scalable.
Mobile Nebula brings this functionality to devices running Android and iOS.
This code is **source-available** meaning that the source is provided for viewing, but we are **not accepting contributions** and provide no license past what the [GitHub Terms of Service](https://docs.github.com/en/site-policy/github-terms/github-terms-of-service#5-license-grant-to-other-users) permit.
See [contributing](CONTRIBUTING.md) for dev-related instructions if you are a Defined Networking employee.

16
RELEASING.md Normal file
View file

@ -0,0 +1,16 @@
# Releasing
## Prerelease
Push a git tag `v#.#.#-##`, e.g. `v0.5.1-0`, and `.github/release.yml` will build a draft release and publish it to iOS TestFlight and Android internal track.
`./swift-format.sh` can be used to format Swift code in the repo.
Once `swift-format` supports ignoring directories (<https://github.com/swiftlang/swift-format/issues/870>), we can move to a method of running it more like what <https://calebhearth.com/swift-format-github-action> describes.
## Release
1. Manually promote a prerelease build from TestFlight and Android internal track to the corresponding public app stores.
2. Mark the associated draft release as published, removing the `-##` from it, ending with a release in the format `v#.#.#`, e.g. `v0.5.1`.
3. Remove the old draft releases that will never be published.
4. Add the notable changes to the app to the release summary, e.g.: <https://github.com/DefinedNet/mobile_nebula/releases/tag/v0.5.1>.