I've seen the feature flag pattern work successfully across large projects many times. A long running feature branch is seldom worth the trouble it brings with merge conflicts.
Once you've done it a couple of times, you start to realize that certain OO tricks can make it easier as well - using factories and inheritance to isolate the new code from the old. If you're successful, once the feature is fully launched you can just delete entire files and their factory invocation and not bits of code within classes here and there. It takes practice though, and might not be as suitable for a distributed OSS team. On Tue, Apr 26, 2022 at 1:16 PM Attila Doroszlai <adorosz...@apache.org> wrote: > Thanks Pifta for starting the discussion. > > I think we can sum up your comparison of feature branch vs. master > development as: the problems we usually have to solve with feature > branches are procedural (busywork), while solutions required for a > comparable master-based model improve the product itself for end-users > as well. > > In addition to the problems you mentioned, I also feel that > development on a feature branch might not get the same level of > attention as the master branch. Fewer people are active on each > feature branch, and we are more likely to take shortcuts since "it's > only a feature branch". Merge vote then places a burden on the rest > of the community, too, if they are to diligently review the changes > introduced over an extended time period in a batch of commits. > > Also, the more feature branches we have in parallel, the more severe > their problems become. > > I strongly favor development on the master branch instead of feature > branches. > > -Attila > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@ozone.apache.org > For additional commands, e-mail: dev-h...@ozone.apache.org > >
