avantgardnerio commented on PR #3191: URL: https://github.com/apache/arrow-datafusion/pull/3191#issuecomment-1219804424
> One thing that might be worth clarifying is how the final merge occurs, I presume we would rebase the integration branch and then do a fast forward merge? I'm not sure if this idea is doable. If it is, I suspect we'd want to: 1. make a commit in datafusion that's one ahead of master that _only_ updates the arrow `version=` to `ref=` 2. active work being done still goes on master 3. we periodically rebase that commit/branch onto master 4. If there's no breaking changes to arrow, the build keeps working and it's not a big deal 5. If there are breaking changes to the arrow API then datafusion changes are required 6. those changes also are done on the `next_release` branch 7. but now it's a pain because if you want to start building a new feature, do you do it off `master` or `next_release`? 8. By logical inference, anything you do this way with `arrow` you also have to do with `sqlparser` and up the chain to `ballista` :( A possible solution is to do the reverse: 1. we keep master always pointed at a `ref=` to arrow 2. we periodically cut release branches as we have been 3. when we cut the release branch, we point it at a version of arrow That way we can keep closer sync between the two repos, and @tustvold , myself, and anyone else doing repo-spanning features don't have to duplicate effort of fixing builds. Are there other possibilities? I don't know. These are all gross, as dependency hell tends to be an unsolved problem unless there are stable APIs. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
