Closed jessesquires closed 7 years ago
cc @rnystrom @Sherlouk
Agreed, master
should be furthest ahead
Probably easiest to continue merging everything into master
then cherry pick non-breaking commits into their own releasable candidate
Should probably update/write new guides to reflect any decisions made here
So workflow for release-2.x
branch would be:
release-2.x
(nit: could we name it minor-release
to use for 3.x?)
release-2.x:master
Is that correct?
IMO the release process is already pretty manual, might as well cherry-pick. Only thing is the CHANGELOG.md
would probably have to have 2 entries: one for next-major and one for next-minor. Right?
I'd assume CHANGELOG.md
would have 2.2.0 in the release-2.x
branch and have 2.2.0 and 3.0.0 in master
Yeah, I guess we could just cherry pick into stable
, and not have a 3rd "staging" branch.
This runs a great risk of conflicts though, and we'd likely get to a point where master
and stable
can never get back in-sync. (we'd have lots of stable
-only conflict resolution, for example).
This is mostly cosmetic with regard to git history, but it will be maintenance burden.
Regardless of the methodology you're going to have conflicts at one point or another
However assuming we keep master
up-to-date with release-2.x
, once we submit the next release stable
and release-2.x
will be the same and master
will only be ahead with breaking commits.
We should never get to a point where there's a conflict going into stable
meaning all conflict resolution will be tested on either release-2.x
or master
.
Assuming everything goes into master
before being cherry-picked into release-2.x
, conflicts will be resolved by PR author into master
and you'd only need to deal with going intorelease-2.x
. Though I don't see that being a massive issue often considering the only difference is breaking changes - and if a non-breaking change is interacting with a breaking change then they would both need to go in the same release anyway.
However assuming we keep
master
up-to-date withrelease-2.x
, once we submit the next releasestable
andrelease-2.x
will be the same andmaster
will only be ahead with breaking commits.
Right, this is exactly what I want the end result to be.
... if a non-breaking change is interacting with a breaking change then they would both need to go in the same release anyway.
Ah, good point. 👍
Ok, I'm on-board with cherry picking into stable
then.
We'll need to:
master
)... (on-going notes)
...
Since the CHANGELOG will be published continuously. However, how GH release notes will remain the same.
@jessesquires Need to update the release checklist as well
Also as per @rnystrom's previous remarks, do we want to rename release-2.x
? Suggestion was minor-release
It's probably ok to create a new branch per minor release now that we're just cherry-picking. We can just use the branch to collect commits, then merge that into stable
, then close it. Cool?
@Sherlouk - Ah, well I think if we're cherry picking then we don't need that staging branch. We can stick with master
and stable
only.
That's simpler. In general, we just need to be very careful and diligent with managing releases.
We'd still need a branch to store non-breaking commits? Unless you were planning to, only on release, go through all the commits and identify non-breaking ones
Feel like that opens the floor for human error, maybe if we do that we should add something to merge commit titles like "[breaking]" as to make it clear?
I think the process would be:
master
stable
Also, before we merge any 3.0 PRs, we should merge master
into stable
so we have a clean start.
While that process would work and probably be fine, I personally don't like the idea of stable
being constantly pushed to.
I prefer the idea of having stable
stable, and only updated when we decide to push a new tested version.
(Just my opinion)
Hm.. yeah.
Really, I'm not a fan of any of this setup. But we have to deal with FB's importing/syncing system.
@jessesquires Do you mind filling me in on what Phabricator/FB internal sync offers?
Interested
Either way I'm happy to go with what you think is best, if that's merging into stable immediately then so be it
@Sherlouk it let's us keep our internal repo the source of truth. Otherwise keeping 2 repos in sync will be a nightmare. We don't have any automation to make GH the source of truth and sync internally due to security concerns (pulling code/files into internal systems automatically = bad).
think we're good here?
For 3.0 breaking changes like #397, we need to agree on a branching model.
We'll need to figure out how we want to manage two on-going releases (2.x and 3.0).
Branching
Suggestion:
master
"linear" and breaking, and have arelease-2.x
branch.release-2.x
is merged frequently intomaster
to keepmaster
ahead, alwaysrelease-2.x
is merged intostable
stable
I think this is probably best (though not optimal, IMO) since IG uses
master
. I went ahead and created the branch: https://github.com/Instagram/IGListKit/tree/release-2.xThe alternative (and more typical model) would be to do the opposite of this and maintain a
release-3.0
branch, but that doesn't play well with IG working off ofmaster
.Commits and PRs
We'll need to do one of two things for all pull requests and commits:
(1) If part of
2.x
, make sure we merge torelease-2.x
. This can all happen via GH only. Then, we (admins) open a PR to mergerelease-2.x
intomaster
and sync FB internal.OR
(2) We continue to merge into
master
only and then cherry pick appropriate commits intorelease-2.x
.Both of have their pros and cons. Either way, concerning our release process so far, we can't simply merge
master
intostable
for releases.