The answer to all your questions is “like any other library” - this is a procedural hack to ease development. There are alternative isomorphic hacks, like compiling source jars from Accord and including them in the C* tree, if it helps your mental model.
> you stated that a goal was to avoid maintaining multiple branches. No, I stated that a goal was to *decouple* development of Accord from C*. I don’t see why you would take that to mean there are no branches of Accord, as that would quite clearly be incompatible with the C* release strategy. > On 17 Jan 2023, at 07:36, Mick Semb Wever <m...@apache.org> wrote: > > >>> … extrapolating this experience to multiple C* versions > > To include forward-merging, bisecting old history, etc etc. that's a leap of > faith that I believe deserves the discussion. > >>> - patches are off submodule SHAs, not the submodule's HEAD, >> >> A SHA would point to the HEAD of a given branch, at the time of merge, just >> by SHA? I’ve no idea what you imagine here, but this just ensures that a >> given SHA of the importing project continues to compile correctly when it is >> no longer HEAD. It does not mean there’s no HEAD that corresponds directly >> to the SHA of the importing project’s HEAD. > > > That wasn't my concern. Rather that you need to know in advance when the SHA > is not HEAD. You can't commit off a past SHA. Once you find out (and how does > this happen?) that the submodule code is not HEAD what do you then do? What > if fast-forwarding the submodule to HEAD's SHA breaks things, do you now have > to fix that or introduce branching in the submodule? If the submodule doesn't > have releases, is it doing versioning, and if not how are branches > distinguished? > > Arn't these all fair enquiries to raise? > >>> - you need to be making commits to all branches (and forward merging) >>> anyway to update submodule SHAs, >> >> Exactly as you would any library upgrade? > > > Correct. submodules does not solve/remove the need to commit to multiple > branches and forward merge. > Furthermore submodules means at least one additional commit, and possibly > twice as many commits. > > >>> - if development is active on trunk, and then you need an update on an >>> older branch, you have to accommodate to backporting all those trunk >>> changes (or introduce the same branching in the submodule), >> >> If you do feature development against Accord then you will obviously branch >> it? You would only make bug fixes to a bug fix branch. I’m not sure what you >> think is wrong here. > > > That's not obvious, you stated that a goal was to avoid maintaining multiple > branches. Sure there's benefits to a lazy branching approach, but it > contradicts your initial motivations and introduces methodology changes that > are worth pointing out. What happens when there are multiple consumers of > Accord, and (like the situation we face with jamm) its HEAD is well in front > of anything C* is using. > > As Henrik states, the underlying problem doesn't change, we're just choosing > between trade-offs. My concern is that we're not even doing a very good job > of choosing between the trade-offs. Based on past experiences with > submodules: that started with great excitement and led to tears and > frustration after a few years; I'm only pushing for a more thorough > discussion and proposal. > > >
