On Thu, Oct 3, 2013 at 6:02 AM, Raphael Kubo da Costa < raphael.kubo.da.co...@intel.com> wrote:
> Hi again, crosswalkittens, > > There's another versioning-related issue we need to talk about. At the > moment, the crosswalk repository has two branches: > > o master, the development branch that never gets frozen and is soon > going to move from 1.29.x.y to 2.31.x.y and track a new Chromium > milestone. > Process wise, we should have bumped the major version to 2.29.x.y as soon as the 1.29.4.0 branch was created (Canaries are always built with the major version that will be promoted into the next stabilization phase.) The bump in Crosswalk major version isn't bound to when Chromium is updated. > > o crosswalk-1, the current stable branch that is supposed to keep > tracking Chromium milestone 29 and is going to become our first > stable release. > > Our Blink and Chromium forks, which Crosswalk depends on, have the > following branches: > > o master, the development branch used by crosswalk's master branch. > > o master_history_28_0_1490_0, master_history_28_0_1500_36 are > "snapshots" of master when it was tracking previous Chromium > releases. We keep them around mainly to preserve history, as each > time we rebase master we lose our merge commits and sometimes remove > fork-specific commits that are not relevant anymore. > > o upstream_28_0_1500_36, upstream_29_0_1547_57 are pristine copies of > the upstream chromium.org branches corresponding to those Chromium > releases. As a corollary, the master_* branches contain our commits > on top of the upstream_* branches. > > These 5 branches above are all related to Crosswalk master, and do not > take Crosswalk's stable branch into account. This has worked so far > because both crosswalk-master and crosswalk-stable are currently > tracking the same Chromium 29 release and milestone, but master is soon > going to switch to Chromium M31, and we need to adjust our forks for > that. > o Should we create crosswalk-1_29_0_1547_57 or something like that? > That is what I would expect, with that branch receiving the security and stabilization patches that are cherry-picked/back-ported from upstream. o master_* branches are not good names, as at some point they are not > going to be used by master anymore. > Perhaps incorporate the crosswalk version prefix into the name? For example: crosswalk-2-chromium-29_0_1547_57 <== Used by canary master (which is building 2.x.y.z) crosswalk-1-chromium-29_0_1547_57 <== Used by crosswalk-1 When canary master switches to chromium-31, a new branch would be created: crosswalk-2-chromium-31_0_XXXX_YY When Canary bumps to 3.x.y.z, it would continue using the last crosswalk-2-chromium-31_* branch until the chromium rebase. The new rebase branch would then be named with the crosswalk prefix as part of the branch name. When Chromium is rebased during the next cycle, then a crosswalk-3-32_0_XXXX_YY branch would be made. Even though Crosswalk's DEPS.xwalk file stores the sha1 of the chromium tree, we would keep the old branch points around to prevent unreachable commits from getting pruned during repository cleanups in the future. o Should we get rid of the upstream_* branches or are they really > needed? > As upstream moves forward with stabilization and security patches, what are your thoughts on the process for cherry-picking/merging those patches from upstream into the Crosswalk stabilization branch? If keeping upstream_* branches helps facilitate that workflow, then that would be the reason to keep them. I can't think of any other reason to keep upstream_* branches. James > _______________________________________________ > Crosswalk-dev mailing list > Crosswalk-dev@lists.crosswalk-project.org > https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev >
_______________________________________________ Crosswalk-dev mailing list Crosswalk-dev@lists.crosswalk-project.org https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev
