The new develop branch

[ErikBjare]

Had a meeting today, talked about a few different things, but mostly I want to document what we said about the new develop branch I proposed.

With NTCS now live, having the master branch be somewhat stable is of importance, but we can't have a million PRs open, so we need a space to merge things that are good enough to use by devs, but not by NTCS participants (until we can run a thorough testing session on the branch and merge it back into master).

So, in order to make progress on PRs like #170, and maybe even #93 and #22, I suggested to @JohnGriffiths that we create a new develop branch and start merging things there.

I'm creating the branch right now, and will target some PRs there.

Still not sure exactly how wild we should get in this branch (can we drop Python 3.7? can I try switching to poetry?), but we can see what makes the most sense as we go.

Edit: One example of a merge process (unlike the one I'm proposing) is the one used by jupyterlab with stable feature branches, to which they backport features: jupyterlab/jupyterlab#12002 (comment). A bit too late for us to go this route with NTCS already live, but could be considered for future iterations.

[JohnGriffiths]

Thanks for documenting this Erik.

The jupyterlab ref is a good one.

I think a 'fairly wild' flavour of dev branch will be the best option for us. We don't have a hugely complex level of backcompatibility to accommodate. Just a handful of core things that need to build and install and run. On the other hand there is a lot of major dev work to be done that could lead to major code base modifications, which makes sense to occur on a dev branch and then move into master as a quasi-release or sub-sub-release type basis.