+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 unreleased features cannot be triggered erroneously in a release. This also gives a longer bake time to avoid unintended consequences of changes.
On Mon, Apr 25, 2022 at 2:09 PM István Fajth <fapi...@gmail.com> wrote: > 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 >
