-
Notifications
You must be signed in to change notification settings - Fork 263
Jetpack Integration Proposal mk2
The previously described versioning scheme makes it hard to know what's actually landed in each version of Firefox, as well as being a pain to manage hotfixes to Beta or Aurora.
As a way to make these things easier, this might make for a better system:
- All main development work happens on github's master branch, just like it always has been.
- At the start of each six-week cycle, a new branch based off of whatever was on master is spun off. (Named "firefoxXX", where XX is the new version of Firefox/Gecko on mozilla-central.)
- During the six-week cycle, new code from the github master branch is merged in to the most recently-created firefoxXX branch, which is then pushed to mozilla-inbound on a weekly or as-needed basis.
If a change from mozilla-central's side changes SDK code, we can then add/commit/push those changes into the firefoxXX branch, then merge that back to master. (Or land the change to master, merge to firefoxXX, then have that go into the next uplift.)
If a change needs to be made to Aurora or Beta (or release, for that matter), you should be able to checkout the appropriate firefoxXX branch and proceed from there. Cherry-pick the change to/from firefoxXX and master if it needs to also be made elsewhere, or just leave it on firefoxXX if it only applies to that version of Firefox.
This system should eliminate the need to tag our repository: You're either working on master branch or your code has landed into a version of Firefox. We shouldn't need to care about tagging what changes week to week, so long as the uplift bug shows the range of changesets, right?