I think this is the same problem that makes the version numbers in the footer on master not look right. My proposed fix in the past was that the release process include merging the release branch back to master after the tag is made. That way all the commits that exist in previous releases exist in future releases.
On Mon, Jul 02, 2012 at 03:49:19PM -0500, Zach A. Thomas wrote: > 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 -- D. Stuart Freeman Georgia Institute of Technology
signature.asc
Description: Digital signature
_______________________________________________ oae-dev mailing list [email protected] http://collab.sakaiproject.org/mailman/listinfo/oae-dev
