JP Version JEP

Here's a proposal for how we can manage version numbers now that we've landed and are shipping in Firefox.

At the start of the six-week Firefox release cycle

• Tag master branch with "firefox-[NEWGECKOVERSION]-dev" (eg, "firefox-23-dev").

For each weekly uplift

• Merge a green master branch cset to integration branch.
• Tag integration branch with "firefox-[CURRENTGECKOVERSION]-[CURRENTDATE]" (eg, "firefox-23-04-02-2012").

Open Questions/Issues

1. We should be able to abandon stabilization and release branches at this point. Main development happens on master, and normal uplifts happen from integration. If we need to uplift to Aurora or Beta (or even Release), we can check out the most recently merged integration branch's tag for that tree (| git checkout firefox-22-04-02-2012 | ), create a new temporary branch based on that tag, cherry-pick/create the necessary changes, tag it like it's a standard uplift (but with the proper Gecko version), and push to try/aurora/beta/etc.
2. Can we get cfx to use these tags to determine the xpi file's min/maxVersions for application support, instead of updating it manually each cycle?
3. Find out if tags can be reused easily. (Tag the last uplift to master for the cycle as "firefox-xx-release", in addition to the date. If any Aurora/Beta uplifts need to happen, pull that release tag, create a new branch for it, tag the changes with the date-based tag as well as reusing the "release" tag to make it easy to get the "latest" set of changes with semi-automated tools.)