It sounds like releasing from branches going forward would solve our problems:
* No more force-pushing master
* No need to rebase after releases
If there are no objections, I would say we should go ahead and do
this. I don't think there is a need for a vote but if anyone wants one
please chime
Note that we already released from a branch in the past, for the 1.0.1
release, if I am not mistaken. In this case we cherry-picked the
patches for the bugfix release on that release branch
(https://github.com/apache/arrow/pull/7933).
+1 to do that also for the main releases to avoid any need of
I have also used the pattern of releasing from a release branch and
cherry-picking (as opposed to merge) fixes from main to the release branch
as needed for the release (on commercial software products), and it worked
well.
As long as you have a regular and frequent release schedule (as Arrow
Personally, I simply don't really understand the aversion for merge
commits. The need to recreate the "master" branch locally after a
release has bitten me several times (git lets you screw that up very
easily...), and it has always been a bit frustrating.
Regards
Antoine.
Le 26/11/2020 à
>
> I don’t have a problem with releasing out of branches. I think I (or
> someone) proposed this in the past and there was not consensus but it seems
> like a good time to revisit the issue.
>
Thanks for the recap. I just couldn't remember where people were at on this.
I'm a big +1 for
I don’t have a problem with releasing out of branches. I think I (or
someone) proposed this in the past and there was not consensus but it seems
like a good time to revisit the issue.
On Wed, Nov 25, 2020 at 7:41 PM Jacques Nadeau wrote:
> I'm catching up here. A couple questions.
>
>- I
I'm catching up here. A couple questions.
- I don't think we should require the inclusion of the release commits
in the main branch. Having leafs created right before release seems to
simplify this and resolve any issues around force PRs, no? Or maybe I'm
misunderstanding something?
Note that at any time you can change your GitHub settings to disallow
your branches from being edited by maintainers.
On Wed, Nov 25, 2020 at 7:51 AM Wes McKinney wrote:
>
> > The first two sound logical, but why couldn't those version bumps be a
> merge commit into master?
>
> We've made the
> The first two sound logical, but why couldn't those version bumps be a
merge commit into master?
We've made the commitment to maintaining a linear commit history in
this project.
Auto-rebasing the PRs at this point is best described as "harm
reduction". The root cause is GitHub's UI which
Is there more documentation why a force push to master is necessary?
I read
https://cwiki.apache.org/confluence/display/ARROW/Release+Management+Guide#ReleaseManagementGuide-Mainsourcereleaseandvote
which says
- The local release branch has some unpushed commits such as bumping to the
next
Hello Jorge,
I know from the past on the Python/C++ side, we needed to do this for a lot of
contributors to enable them to work with their branches/PRs again as they were
overwhelmed with the complexity of these rebases. Personally, I wouldn't like
to spend much time on whether we should
Hi,
Based on a discussion on PR #8481, I would like to raise a concern around
git and the post-actions of a release. The background is that I was really
confused that someone has force-pushed to a PR that I fielded, re-writing
its history and causing the PR to break.
@wes and @kszucs quickly
12 matches
Mail list logo
