| Re: [papyrus-rt-dev] Feature freeze and git repo |
|
Ø
While it's true that between feature freeze and release we should focus on testing and fixing bugs, I think having a branch that fully builds new features could be helpful and simplify the integration of new
features once we release. I'm not sure I like having pending changes hanging on Gerrit particularly in the case where there is more than one Gerrit on top of another, which become a pain to merge later on. And I also prefer having few items in my Gerrit dashboard
;) I agree; that’s exactly why we wanted to experiment this for the Neon/Oxygen transition. As it happens, the Oxygen branch
has not been used yet, but at least we have a place where new features can be integrated, built and tested if we ever need it Ø
In fact, the "anti-gitflow" approach advocated in [2] seems to be closer to what you describe: Much closer indeed, except for the “Release” part of this article: our Maintenance branches have to evolve in parallel
to the master branch, so they remain forever, and we indeed have duplicate (“cherry picks”) commits between Maintenance and Master branches. We can’t merge these branches, because versions evolve independently (e.g. when Mars moves from 1.1.0 to 1.1.1, Neon
M1 goes from 1.1.0 to 1.2.0. Also, some fixes involve breaking APIs, so we usually implement a quick workaround for the maintenance branch, and a proper, larger fix on master). So we actually need maintenance branches that remain forever. Regards, De : papyrus-rt-dev-bounces@xxxxxxxxxxx [mailto:papyrus-rt-dev-bounces@xxxxxxxxxxx]
De la part de Ernesto Posse I like the idea of a temporary branch for new features, a little bit like in the gitflow model [1], although that seems to use a merge approach rather than a rebase approach like us, and it has its drawbacks [2]. In fact, the "anti-gitflow" approach advocated in [2] seems to be closer to what you describe: consistent with the goal of keeping a linear history, making other branches temporary, creating a branch for the release (i.e. the "maintenance"
branch). That sounds good to me. While it's true that between feature freeze and release we should focus on testing and fixing bugs, I think having a branch that fully builds new features could be helpful and simplify the integration of new features once we release. I'm
not sure I like having pending changes hanging on Gerrit particularly in the case where there is more than one Gerrit on top of another, which become a pain to merge later on. And I also prefer having few items in my Gerrit dashboard ;) So if we are voting, I'd vote for having a feature branch, renaming 'master' to 'maintenance' after release and rebasing the feature branch. On Tue, May 17, 2016 at 4:20 AM LETAVERNIER Camille <Camille.LETAVERNIER@xxxxxx> wrote:
|