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 <fapi...@gmail.com> 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 > features.... > > Currently we are using feature branches to start developing large new > features. > We see the drawbacks of this with long running developments like EC or FSO, > where the burden of keeping the feature branch up-to-date, and switching > between the feature branch and master is a hassle due to divergence between > protocols (with that the need for rebuild every time when switching from > the feature branch to master and vice versa), hard to solve merge > conflicts, testing problems, and so on... This leads to possibly early > merges, which then are able to block us from cutting a release at a time we > would want to do a release as there are some remainings to solve before > cutting a release due to the merged feature. > > I am sure there is a burden as well with master based development, where we > would need techniques to be implemented in order to have features that we > can enable at will (via feature toggle for example), but wouldn't it be > worth the effort? > I see problems with this as well, like how to hide something behind a > toggle effectively, especially when it has to change one small thing in a > large complex algorithm... Also I see problems around enabling things on > the client and server side together, maybe causing extra work on > compatibility problems that are coming from on disk, or in rocksdb data > changes for example... > > But... What we would gain is the ability to cut off a release anytime with > features half done, but turned off, with features that we can turn off > permanently in a release in a static way in the code or in case of beta > quality via a configuration... > > Maybe this is not the right time to switch, we may have exceptions in the > future as well, due to the complexity of adding a feature toggle for a > given feature, but in general there have to be ways/there have to be > features with which we can start using some techniques and later on mandate > the existence of a feature toggle for every new feature... Would that be a > better word for us? > > -- > Pifta >
