Closed robertroeser closed 5 years ago
In case this will be a default flow for every contribution, then - I would recommend avoiding using an external tool since every contributor would require to use that which will complicate external contribution. I would propose to work on a more extensive contribution guide which will cover how every PR feature/bugfix
should be constructed/formed as it is done in reactor-core so every contributor will be mandated to follow the guide rather installing an additional tool.
Otherwise, the proposal makes sense, in case we use that for internal stuff, general release process, etc
My only complaint is that I don’t find the use of the develop
branch in GitFlow to be particularly useful. The idea of topic branches, off of master
(or version branches if we ever support two branches simultanesously) rebased and merged back to master is worthy, but the extra layer of indirection seems totally unnecessary.
This is a a weak objection though, so let’s just quickly pick something better than what we are currently doing and impose it for consistency.
@OlegDokuka - good idea we can use the reactor-core contribution guide as a starting place, and edit where appropriate
Will do that. Assign that on me.
I pushed a master and develop branch that is in sync with 1.0.x, and made develop the default branch
We keep commiting to RSocket on branch 1.0.x, from various other random branches. I propose that we use Git Hubflow for a branching strategy and move off 1.0.x
Here's a link to Git HubFlow https://datasift.github.io/gitflow/