The current versions of those apps rely on mem3, clustering, adding nodes, etc and they will trail behind the 3.x versions since developers wouldn't think to port those updates to main since they are simply non-functional there. Most of those apps have to be re-written from scratch and it would be better to start from the recent working versions on 3.x. The tests for those apps don't really fail as we get green builds on PR branches to main. We simply don't run them at all and only run a subset of applications (fabric, couch_jobs, couch_views and a few others).
Don't think this is about a 4.x release per-se. This is mainly about cleaning up, reducing the cognitive load of anyone jumping in trying to work on main and seeing applications and endpoints calling into non-existing applications. -Nick -Nick On Mon, Apr 12, 2021 at 1:13 PM Joan Touzet <woh...@apache.org> wrote: > > Generally +1 with one major reservation: > > On 12/04/2021 12:25, Nick Vatamaniuc wrote: > > * Some applications we want to have in main, but the way they are > > implemented currently rely completely or mostly on 3.x code: purge > > logic, couch_peruser, global_changes, setup. I am thinking it may be > > better to remove them from main as we'll have them on the 3.x branch > > they'll be recent (working) there. When we're ready to fix them up, we > > can copy that code from there to the main branch. > > If the intent is to release 4.0 with them, then I would suggest keeping > them there and allowing their tests to fail so we know that a "failing > main" means that the product isn't ready to release yet. > > If we are pushing these out past a 4.0 release, then that decision needs > to be made formally. > > Parenthetically, we try to avoid "code owners" here, but usually fixes > to couch_peruser and setup fall to Jan, while purge and global_changes I > *believe* have generally been made by IBM/Cloudant. > > -Joan "not sure main is ready to be called 4.0 yet anyway" Touzet