On 10/5/19, 7:08 AM, "Carlos Rovira" <[email protected]> wrote:
Hi Alex,
- release: Here's where I see differences. Once we decided we want to
release, is because develop has the final state to cut a release. No more
commits are needed for that release. So once a RM start the process and
creates release branch from develop, then no more things should go to
release branch. NOW: If we have to fix something for release, this is done
in release and then "merged" (not cherry-picked) to develop at any time.
Finally as we get to the final process, release is merged in master and
develop.
Notice that in parallel: develop can continue to evolve, but that will not
go into that current release, will go to the next.
As well, I think Cherry pick can be an option for many other use cases. Is
like using rebase, those are very powerful tools to use when needed. Just
we all need to know when is the right way to use it.
I think the problem right now is that when we start the release, we
continue with open mind to add all we do in develop. This is due to our
current release process getting to long in time. I think next release
process should be very less time and will be less new things in develop so
what we have in release will be what we really release, instead of continue
adding new develop things.
IMO, because we don't have dedicated testing, we are going to find important
things when we start testing the release branch. So it isn’t "if we have to
fix something for release" it is "when we have to fix something for release"
and I am asking the other committers to be more careful in the next release and
not just commit stuff to develop. Be aware if a release is in progress and get
agreement to push your fix to the release branch.
I sure hope the release branch is open only for a much shorter time, but I'm
also sure we will find something to fix in almost every release.
-Alex
