Okay, so then I guess the policy is that 0.0.x releases are to be non-breaking changes only. Reasonable enough… perhaps, if it’s not already documented, such release policies/standards should be spelled out somewhere.
2 Likes
Sure. Where?
I was thinking maybe the CONTRIBUTING.md document in the repo, if it’s not already there or somewhere else. I’d volunteer to write it up, but I don’t know all the standards. 
Edit: Actually that kind of thing is also good to know for regular JME users considering upgrades, so maybe a “Versioning Policy” section should be on the main GitHub page or somewhere more visible.
2 Likes
Here’s what I propose adding to CONTRIBUTING.md:
Customs around integration, branching, tagging, and releases
- Most pull requests are integrated directly into the
master
branch of the repository. - Unless the history of the pull request is important, it should
be integrated to a single commit using “squash and merge”.
If the history is important, favor “rebase and merge”.
Don’t create a merge commit unless GitHub cannot rebase the PR. - For each major release (such as v3.0 or v3.3), an appropriately named
release branch is created in the repository. - For each minor (or “dot-dot”) release (such as v3.2.3), an appropriately
named tag is created in the repository. - In general, library changes that plausibly might break existing apps
appear only in major releases, not minor ones.
3 Likes
Yeah, that certainly clears some things up for me.
I do believe the JME repo has auto-squash enabled, btw, if it matters. Git policy stuff is also good to include, good idea.
1 Like
I believe GitHub’s integration policy is set on a per-user basis. It remembers what you used last time you integrated a PR.
Thought it was a repo thing for some reason - I’ll take your word for it then.
1 Like
I mean, we as approvers just know we’ve had many times were PRs weren’t squashed. So then we reverse engineer “how that happened” from there.
Whatever setting we have on our repo, folks seem to manage to submit unsquashed PRs.
2 Likes
@sgold I made a PR with the proposed changes:
2 Likes
When integrating a PR, GitHub provides the integrator with the option to easily squash it into a single commit. Therefore, I see squashing PRs as an integrator’s responsibility, not a developer’s responsibility.
1 Like
Keep in mind, if the changes themselves are already approved, there is a third option here:
The ‘integrator’ can do a more involved rebase ‘by hand’ using local git commands. It’s usually possible to do a clean rebase here, every if it takes a couple of steps. Then git push -f back up to the pr-branch.
I’m aware that force-pushing a public branch has risks, but they don’t really apply if the pr is going to be merged immediately after - that branch will no longer be used as the base for future development.
1 Like
Doesn’t that assume that the integrator has permission to modify the PR?
Yes, but you can click that when opening a PR in Githubs GUI, IIRC, so that’d be the easy part
1 Like
For creating PRs, I always use GitHub’s web interface. I’ve never seen such a checkbox.
I guess he means this checkbox at the bottom right side of PR page.
3 Likes
Just what @Ali_RS showed. It’s checked by default - you need to take action to turn it off. For each PR. The practical upshot is that a maintainer had access to most every PR.
Caveat: you’ll need to do the push with an https:// git remote specification, rather than a git@ remote. (Github supports both for every repo. You’ll just need to use your username and password, rather than an ssh connection)
2 Likes
Glad to know. Thanks, @sailsman63!
Does this impact the proposed additions to CONTRIBUTING.md?
Not that I know of. It was more of a thought for those that have to deal with such a PR.
1 Like
I believe cherry picking for v3.2.4 is complete. There was one change of plan: 7e11a6c had conflicts. I was unsure how to resolve them, so I skipped it.
Now’s a good time to test the v3.2 branch, before the v3.2.4 release is “cut”. Let’s say, in 24 hours … around 1800 hours GMT on 11 July.
3 Likes
There’s been another change of plan. Testing on Linux uncovered a serious physics bug (1141) that had to be fixed in v3.2.4. The fix just went in, so the test window has been extended until about 0600 hours GMT on 13 July.
1 Like