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 fac
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 itsel
I am happy to have any inputs from others about different projects, though
I think this is mainly up to us to decide how we do feature development,
then we should find good practices for the selected way outside. Though I
admit it might be worth it to check how other projects do it and what
problem
+1 to keeping master shippable. In addition to config flags, for purposes
of the upgrade finalization, many new features would need to be gated, one
option would be to make the validators expect a version that is only
possible by hand tweaking the version in a dev build, thus ensuring that
unreleas
Our of curiosity, how other major Apache project do this? Like spark, nifi
or airflow?
Le lun. 25 avr. 2022 à 22:09, István Fajth a écrit :
> Hi,
> I was inspired with the latest discussions around compatibility guarantees,
> and cutting a release to bring up a question about how we develop new
Hi,
I was inspired with the latest discussions around compatibility guarantees,
and cutting a release to bring up a question about how we develop new
features
Currently we are using feature branches to start developing large new
features.
We see the drawbacks of this with long running developm
