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 problems they have with the selected method, while we already see what problems we have now, but I did not spend time with research so far.
In the current state, we seem to have opted into an unstable master from which we can not release whenever we want, and we do not have strict rules about what we merge. Ozone is not that mature so this - I think - is acceptable for now, and we should discuss in the thread about 1.3.0 that, how we will get out of this state, while this seems to be equally important to discuss about how we want to avoid such a state in the future, hence I started this thread. Michel Sumbul <michelsum...@gmail.com> ezt írta (időpont: 2022. ápr. 25., H, 23:13): > 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 > > > -- Pifta
