Opened 9 years ago

Closed 9 years ago

#701 closed discussion (wontfix)

avoid release merge conflicts

Reported by: Peter Owned by: Peter
Priority: minor Milestone:
Component: build Version: trunk
Keywords: Cc:

Description

When merging a release into trunk there is always a conflict in m4/version.m4 or sometimes worse, i.e., that the change slips through into trunk. The change typically looks like this

+ m4_define([PATCH_VERSION], [1]) 
- m4_define([PATCH_VERSION], [0]) 

and should obviously not be propagated into to trunk.

After reading this bug-automake thread (especially Peter Rosin's email), I wanted to mention here how we possibly could learn something from Automake here. They use git, which is more merge friendly so perhaps their approach would become overly cumbersome when using subversion.

They basically have three branches; we'd call them trunk, maint, and 0.8-stable. They heavy work is carried out in the trunk, minor bug fixes is carried out in maint. Changes in maint is then merged into trunk and 0.8-stable (and possibly 0.7-stable). Commits that will not be merged into trunk e.g. bumping version number is carried out in 0.8-stable.

The obvious downside is that Release Manager needs to jiggle with three branches during the release. How does that compare to the problematic version.m4 merges?

As mentioned above, not sure how subversion would handle frequent merges from maint into both 0.8-stable and trunk.

Change History (1)

comment:1 Changed 9 years ago by Peter

Milestone: yat 0.x+
Resolution: wontfix
Status: newclosed

The main problem, undetected merges of PATCH_VERSION updates, was solved in r2729. Having a maint branch seems overkill.

Note: See TracTickets for help on using tickets.