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
Simplify versioning documentation with Laravel-inspired approach
- Reduce length by 70% while maintaining all essential information
- Add explicit semantic versioning reference and link
- Adopt Laravel's direct, confident tone and structure
- Focus on practical information developers need
- Remove verbose examples and repetitive explanations
- Maintain mobile-specific versioning concepts (patch vs minor releases)
- Keep OTA compatibility messaging and composer integration guidance
This document outlines how NativePHP Mobile itself will be versioned moving forward. As we develop tools to assist with OTA updates and full app bundles, our versioning strategy ensures predictable release cycles and update compatibility.
8
+
NativePHP Mobile follows [semantic versioning](https://semver.org) with a mobile-specific approach that distinguishes between Laravel-only changes and native code changes. This ensures predictable updates and optimal over-the-air (OTA) compatibility.
9
9
10
-
**Note**: You can version your own applications however you prefer - including codenames, custom schemes, or any versioning pattern that works for your project. This document specifically covers how NativePHP Mobile releases will be versioned.
11
-
12
-
## Our Release Types
13
-
14
-
### Patch Releases (Laravel-Only Changes)
15
-
16
-
When NativePHP Mobile updates contain only Laravel/PHP code changes, we will increment the patch version:
17
-
18
-
-**Laravel code improvements** - Core functionality, API enhancements, bug fixes
# Example: New camera feature requiring native code updates
45
-
1.2.3 → 1.3.0
46
-
```
47
-
48
-
**Deployment**: These updates require developers to rebuild their applications and submit new versions to app stores.
49
-
50
-
## Why This Versioning Strategy Matters
51
-
52
-
By following this consistent versioning pattern, we guarantee:
53
-
54
-
1.**Predictable Update Impact** - Patch versions are safe to update without rebuilding apps
55
-
2.**Clear Breaking Change Communication** - Minor versions signal when native rebuilds are required
56
-
3.**OTA Update Compatibility** - Our tools can safely determine which updates can be deployed over-the-air
57
-
4.**Developer Confidence** - You know exactly what each version bump means for your development workflow
58
-
59
-
## Version Examples
60
-
61
-
### Patch Version Scenarios
62
-
63
-
```bash
64
-
# Bug fix in package command
65
-
1.2.3 → 1.2.4
66
-
67
-
# New Artisan command added
68
-
1.2.4 → 1.2.5
69
-
70
-
# Change the way we move files around on Windows
71
-
1.2.5 → 1.2.6
72
-
73
-
# Composer dependency security update
74
-
1.2.6 → 1.2.7
75
-
```
76
-
77
-
### Minor Version Scenarios
78
-
79
-
```bash
80
-
# New camera API integration
81
-
1.2.7 → 1.3.0
82
-
83
-
# iOS-specific push notification changes
84
-
1.3.0 → 1.4.0
85
-
86
-
# Android permissions handling update
87
-
1.4.0 → 1.5.0
88
-
89
-
# New native file system access
90
-
1.5.0 → 1.6.0
91
-
```
92
-
93
-
## Impact on Your Development
94
-
95
-
### For Patch Releases
96
-
97
-
When we release a patch version:
98
-
-**Update immediately** - Run `composer update` to get the latest improvements
99
-
-**No rebuild required** - Your existing native apps continue working
100
-
-**OTA compatible** - Any improvements are immediately available to your users
101
-
102
-
### For Minor Releases
103
-
104
-
When we release a minor version:
105
-
-**Update package** - Run `composer update` to get the latest version
106
-
-**Reinstall native code** - Run `php artisan native:install --force` to update native components
107
-
-**Review changelog** - Check what new native features or changes are included
108
-
-**Test thoroughly** - Ensure compatibility with your existing application code
109
-
-**Submit to app stores** - New native code requires store approval
110
-
111
-
## Release Communication
10
+
## Release Types
112
11
113
12
### Patch Releases
114
-
-**Immediate availability** - Available via Composer as soon as released
115
-
-**Minimal disruption** - No impact on your release schedule
116
-
-**Automatic compatibility** - Works with existing native builds
13
+
**Laravel/PHP code only** - Bug fixes, new Artisan commands, configuration updates, documentation, and dependency updates that don't affect native code.
117
14
118
-
### Minor Releases
119
-
-**Advance notice** - Announced ahead of time to allow planning
120
-
-**Migration guides** - Documentation for any required changes
121
-
-**Testing period** - Beta releases available for early testing
15
+
- Safe to update immediately via `composer update`
16
+
-No app rebuild required
17
+
-Compatible with existing native builds
18
+
-Perfect for OTA updates
122
19
123
-
## Implementation Details
20
+
### Minor Releases
21
+
**Native code changes** - New native APIs, Kotlin/Swift updates, platform-specific features, or native dependency changes.
124
22
125
-
### Version Code Management
23
+
- Require rebuilding your app with `php artisan native:install --force`
24
+
- Need app store submission for distribution
25
+
- Include advance notice and migration guides
126
26
127
-
Our version codes follow this pattern:
27
+
## Support Policy
128
28
129
-
```bash
130
-
# Version 1.2.3 = Version Code 123
131
-
# Version 1.2.4 = Version Code 124
132
-
# Version 1.3.0 = Version Code 130
133
-
```
29
+
### What's Safe to Update
30
+
-**Patch releases** - Update immediately without rebuilding your app
31
+
-**Minor releases** - Plan for rebuild and app store submission
134
32
135
-
### Composer Integration
33
+
### Version Constraints
34
+
Use semantic versioning constraints in your `composer.json`:
136
35
137
36
```json
138
37
{
139
38
"require": {
140
-
"nativephp/mobile": "^1.2.3"
39
+
"nativephp/mobile": "^1.1.0"
141
40
}
142
41
}
143
42
```
144
43
145
-
Using semantic versioning constraints ensures you receive patch updates automatically while controlling when to adopt minor releases.
44
+
This automatically receives patch updates while giving you control over minor releases.
146
45
147
46
## Your Application Versioning
148
47
149
-
While NativePHP Mobile follows this structured approach, **you have complete freedom** in how you version your own applications:
150
-
151
-
-**Semantic versioning** - `1.2.3`, `2.0.0`, etc.
152
-
-**Codenames** - `"Falcon"`, `"Eagle"`, `"Hawk"`
153
-
-**Date-based** - `2024.01.15`, `2024.02.01`
154
-
-**Build numbers** - `Build 1234`, `Version 5678`
155
-
-**Custom schemes** - Whatever works for your project
156
-
157
-
The key is that regardless of how you version your app, NativePHP Mobile's consistent versioning ensures you always know the impact of framework updates on your development process.
158
-
159
-
## Benefits of This Approach
160
-
161
-
### For Developers
162
-
-**Predictable updates** - Always know what to expect from version bumps
163
-
-**Reduced friction** - Patch updates don't disrupt your release cycle
164
-
-**Clear upgrade paths** - Minor versions provide structured upgrade opportunities
This versioning strategy enables us to deliver improvements quickly while maintaining the stability and predictability you need for production applications.
48
+
You have complete freedom in versioning your own applications - use semantic versioning, codenames, date-based versions, or any scheme that works for your project. NativePHP Mobile's consistent approach ensures you always understand the impact of framework updates regardless of your chosen versioning strategy.
0 commit comments