I can't tell what you're proposing, Ray. That commits should not be merged into a release branch until after they've landed in master? The way it's supposed to work is that when we branch, any commits made to the branch should probably wind up in master. I say "probably" because we occasionally have a patch in the branch that fixes something that doesn't pertain to master (say, for instance, if an offending method exists in the branch, but no longer exists in master. The other way master is guaranteed to diverge is in the version numbers for all the artifacts) When we tag, it corresponds to a moment in time on the release branch, but not to master. Their commits diverge because their needs diverge. This selective merging is subject to human error, as you point out.
One way around it would be not make any release branches, and only release from master. This would require us to be more careful about potentially destabilizing changes, but maybe we should be anyway. Zach On Jul 2, 2012, at 3:27 PM, Ray Davis wrote: > While helping prepare our local branches for a 1.3.0-based upgrade, I > ran into a couple of "lost" commits that were included in OAE 1.2.0 but > never in "master" (and therefore not in 1.3.0). [1] The end result is > that Nakamura 1.2.0 had a couple of test files that don't appear > anywhere else: > > bundles/files/migrator/src/test/resources/KERN2759Redux.json > bundles/files/migrator/src/test/resources/StructureWithBasicLti.json > > and a couple of changed lines in the release scripts at: > tools/release_post_process_files.sh > tools/release_pre_process_files.sh > > Obviously no one found these to be blockers but they do muddy history a > bit. More generally, we've found that the OAE teams' current handling of > releases makes it surprisingly difficult to keep our local production > branches aligned with central development. > > As background, one of the more dubious advantages of Git over Subversion > is its tags approach. Rather than referring to a particular point on a > branch, a tag has its own completely independent history. It's like an > unnamed branch with a named end-point. Project teams can still use tags > in a familiar way by being disciplined about keeping all commits (and > therefore all tags) on the "master" branch. Unfortunately (from our > point of view), the OAE team has taken full advantage of tag > independence, and a given tag rarely corresponds to a commit on "master". > > If this wasn't a thoroughly considered team policy but instead > just-sorta-happened, could the project team reconsider it? > > Best, > Ray
_______________________________________________ oae-dev mailing list [email protected] http://collab.sakaiproject.org/mailman/listinfo/oae-dev
