It seems like it will cause less disruption if I put the new stuff on a branch. Unless someone asks I'm going to keep the same version, 3.0-SNAPSHOT. So, don't push snapshots off the branch :-)
Unless I can figure out some git magic I'm going to do this by applying the work to trunk, moving trunk to the new branch, and restoring trunk. I'm going to try to condense the git commits a bit so each one is fairly substantial but don't plan to spend a lot of time on this. I expect to do this tomorrow. thanks david jencks On Apr 25, 2011, at 7:36 PM, Kevan Miller wrote: > > On Apr 25, 2011, at 5:37 AM, Shawn Jiang wrote: > >> With the later options, we need to re-setup m2 dev/AHP/build environment >> immediately and have to maintain two set of code for tck for an unknown >> period. I'd prefer the sandbox/branch instead of branching current trunk >> before major potential issues in the new kernel is resolved. > > I"m ok with that. As long as trunk changes are being merged into the new > branch. > >> >> Here are the possible working logic if choosing the sandbox option: >> >> 1, Run full tck/SVT against the sandbox branch to find the gaps. >> 2, Keep resolving the Major issues until we are comfortable to put it into >> trunk. >> 3, Branch current trunk to new M2 when the sandbox branch is ready. >> 4, Merge the sandbox branch to trunk. > > The key will be when 2 occurs. Hopefully, it will be soon... > > --kevan
