How do we handle releases / other git related issues

[GGAlanSmithee]

It just occured to me, when I merged #927 that it wasn't clear to me how we handle releases, and who is responsible for it.

Some questions that I would like to see answered:

• Who makes releases?
  • What does this include? (git tags, etc)
• Who / How merges new functionality into feature branches?
• When do we update the changelog
  • Within the scope of a PR or as we make a release?

CC @reactGo/admin (can you ping like this?)

[slavab89]

That's a great question! 😄
I'm working mostly with Bitbucket but i'll try to answer based on what i know/understand (Please correct me if i'm mistaken)

• Whoever is defined as an admin in a project can make a release. If you go to the releases page you should be able to see Draft a new release button. This will take you to a page that you can write some text about the release (Maybe a changelog or something) and once you're done it will also create a tag with the relevant version.
• It is also possible to do it through cli but i didnt try this yet.
• Its possible to use standard-version to change the package.json version + tag + generate changelog and then use conventional-github-releaser to make a GitHub release. It does require to use some commit message convention for the changelog to be generated correctly.
• Regarding merges, anyone who's defined as an admin here can make a merge (Or are you asking because you want a single person to be responsible for it?)
• Also, we can set up a CI process or something since we do have tests here (That hopefully pass?)

I wonder if there is like a private channel or something like that for us to speak about those things.

Also, i didnt get a notification with that CC =[

[GGAlanSmithee]

@slavab89 thanks for the info, to bad the CC didn't work.

The info about how to make a release technically is really great, and I definitely agree on having a CI process. I was even more curious about who is responsible for releases administratively though.

• Who keeps the changelog up to date?
• Who keeps features branches up to date?
• Who decides when to release?
• More questions?

I guess we can solve atleast the change log question, by making it a requirement in each PR, but that would put the burden on the contributor.

[choonkending]

Sorry for the late reply. I used to release and update the changelogs myself every time based on the PRs. Hehe.

…

On Sun, 5 Nov 2017 21:05 Alan Smithee ***@***.***> wrote: @slavba89 thanks for the info, to bad the CC didn't work. The info about how to make a release technically is really great, and I definitely agree on having a CI process. I was even more curious about who is responsible for releases administratively though. - Who keeps the changelog up to date? - Who keeps features branches up to date? - Who decides when to release? - More questions? I guess we can solve atleast the change log question, by making it a requirement in each PR, but that would put the burden on the contributor. — You are receiving this because you are on a team that was mentioned. Reply to this email directly, view it on GitHub <#928 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ADnMbVgxqBRmYRSePqhnopWJtnoeHLhOks5szYh_gaJpZM4QAhLP> .

[slavab89]

@choonkending Did you write the changelogs yourself? 😱 i salute you!

Regarding the changelog, i believe that we should be the ones that update it. What i was trying to say regarding the use of (standard-version)[https://github.com/conventional-changelog/standard-version] is that the process would be:

1. A contributor creates some PR and lots of commits
2. CI runs on the PR making sure everything is ok.
3. The administration decides to merge that PR. I think that the way we should do it is "Squash + Merge". The reason is that the interesting thing that the contributor did is the whole PR, if it has 20 commits where most of them are small fixes (wording, lint etc.) i dont really want them in the final master branch, i want 1 commit with the PR code. Regarding the commit message, i believe that it allows you to reword it during the merge (does it?)
4. Once the administration decides to make a release / new version, we can run standard-version + conventional-github-releaser (since we probably can control the final message convention of the contributors) to bump the version and create a new release.

Who is administration that decides when to release is...? 😝

Also, we could use commitizen to guide contributors on the commit message convention.

Regarding feature branches. I'm not 100% on this, make @choonkending could tell us how he did it. But some of the PR's and changes can just be rebased onto the feature branches (For example, like the last one that @GGAlanSmithee did, with the serialization). Other changes that needs to be more custom, maybe cherry-pick commits?

Let me know what you think about all of this. I too am always looking to improve the workflow.

[choonkending]

Who is administration that decides when to release is...?

I think whoever is on the admin team @slavab89 @GGAlanSmithee @ZeroCho or myself can discuss on the issue whether to cut a release.

I used to decide whether to do a patch, minor or major version based on semver, and personally tried to write commit messages described by Linus Torvalds here.

I'm happy for you to decide on standard-version and commitizen if that helps with the workflow!

I think that the way we should do it is "Squash + Merge".

👍

Thanks all for contributing so much!