Stefano Lattarini skrev 2011-12-22 09:41: > On 12/22/2011 08:26 AM, Peter Rosin wrote: >> Hi! >> > Hi Peter. > >> Since the msvc branch has been merged into both branch-1.11 and master, >> it seems natural to also merge it into maint. No? >> > I'd rather not. First, it wouldn't be useful, since we do 1.11.x maintenance > releases from branch-1.11 only, we plan to do the next 1.12 release from > master, and both of these branches already contain the features from msvc.
I'm ok with that. However, ... > Second, and more important, the versions of msvc merged into branch-1.11 and > master are sligthly different, in that the one on branch-1.11 doesn't have > the new `extra-portability' warnings enabled by -Wall (this is required for > backward compatibility, which a maintenance version should pay particular > attention to, but is not a behaviour we would want to carry in future > versions, for reasons you had so eloquently explained in a past discussion). ... I don't believe this to be true. The (important) differences you describe are indeed part of branch-1.11, but not msvc. They were added to the msvc-for-1.11 branch which was then merged into branch-1.11 leaving the original msvc branch free from this issue. The only (non-merge) commits in msvc that are not also in master are: b722b108 "news: fix suboptimal wording" 620ba14f "tests: various minor tweakings, mostly related to AM_PROG_AR" (unless something has been merged into msvc via maint that has not yet been merged into master, but that *should* be benign) Those two commits are already in branch-1.11, and I don't see how merging msvc into maint is going to cause any trouble. And indeed a (throwaway) merge of msvc into maint and then maint into master show only the inevitable conflicts in NEWS and a trivial-looking conflict in syntax.test. > So, if we merge msvc into maint as-is, that would create merge conflicts when > we merge maint back into branch-1.11, and worse, would cause the code from > maint to have a behaviour more similar to that of the next major version than > to that of the next maintenance version. OTOH, we could backport the hacks > for 1.11.2 into maint, and confuse the already-too-messy automake history > even more. Neither of these two possibility should particularly appealing to > me, given that in the end they do not offer any real advantage anyway. This is a conclusion from your above faulty assumption, I believe, and continuing the (throwaway) merging, merging maint into branch-1.11 after the above (naturally) adds nothing to branch-1.11. But it was just a suggestion. If you don't want it, then I won't insist. Cheers, Peter
