Cut 2.2.0 release

[rnystrom]

Launch Checklist

• [ ] Run through documentation one last time checking header docs, formatting, and links (e.g. Guides)
• [ ] PR podspec version update to 2.2.0 against master
• [ ] Add 2.2.0 release with changelog as notes
• [ ] Run pod install on examples
• [ ] PR master against stable with latest commit
• [ ] Confirm stable is 0|0 ahead/behind
• [ ] Publish GH release
• [ ] $ pod spec lint locally and with CI
• [ ] Push updated podspec with $ pod trunk push IGListKit.podspec
• [ ] Verify 2.2.0 picked up on Cocoapods including new documentation
• [ ] Test $ pod install on hobby weather app to see update
• [ ] Send out tweestorm

[rnystrom]

@Sherlouk @zhubofei feel free to jump on any of these w/ PRs if you want 💪🤓

[jessesquires]

lol - sorry I'm behind on this.

Those steps don't work with our new workflow.

Some notes:

We can't merge master into stable because it has 3.0 commits in it.

We (I) have been cherry-picking into stable -- which I'm not convinced was a great idea because it creates new commits. So we'll never be 0 | 0, unless we merge stable into master but I'm not sure what that will actually do regarding history.

We'll need to gen docs on stable and then PR that into master since gh-pages only works via master/docs.

[jessesquires]

I think we should update our future workflow to be:

1. merge current release changes into stable first (for example, anything for 2.x)
2. then periodically merge stable into master
3. continue to merge next release changes into master (for example, 3.0 changes)

This way, master will always be N ahead of stable but 0 behind. Then for the next major release (e.g. 3.0) we can simply merge master into stable and everything should be in sync at 0 | 0.

[jessesquires]

Ok. Branches are synced up via cherry-picking.

Picked 12 commits from master to stable: https://github.com/Instagram/IGListKit/branches

Compare list of commits:

https://github.com/Instagram/IGListKit/commits/master

https://github.com/Instagram/IGListKit/commits/stable

[rnystrom]

@jessesquires so if we had 3.0.0 stuff done before 2.2.0 was released, we would just hold the PR in limbo until 2.2 is out, then land?

[jessesquires]

No no:

• 3.0 PRs merge into master
• 2.x PRs merge into stable

Then we PR from stable to master. This would keep history clean.

[rnystrom]

Oh! I get it. I like that idea a lot.

[Sherlouk]

Drafted the version on GH: https://github.com/Instagram/IGListKit/releases/tag/untagged-a3de6033bf518248eace

Will jump on version bump (Podspec etc) now

[Sherlouk]

Really when we come to doing releases, once the cherry-picking process has been done in order to get all the specific commits over into stable, we should then no longer push commits to master until the release is done.

Otherwise we're going to have to keep redoing that step with every PR, for example the recent changelog updates. It'd be better if we did that straight onto stable and once all changes are done and release is published then just do a final stable into master PR to get everything across and ready for the next release!

[Sherlouk]

@rnystrom @jessesquires We got an agreed branching strat yet? If so let's document it!

[rnystrom]

@jessesquires branch protections removed, should be able to move forward w/ 2.2

[jessesquires]

@rnystrom - yep, I'll see what I can do later today/tomorrow

[rnystrom]

Ok, our branches and sync strat messed things up a bit. We're going to abandon 2.2 and push harder to get 3.0 out the door soon-ish. Apologies!

[jessesquires]

Booking keeping is all done.

• Updated milestones
• Fixed up branches

https://github.com/Instagram/IGListKit/branches

[jessesquires]

For anyone waiting on the 2.2 release -- sorry for the confusion and hiccups! Hopefully we can get 3.0 out sooner.