@b hey there, if you haven't watched it yet I can recommend this video - https://simonrepp.com/video/faircamp/going-online/ - especially the first 5 minutes or so. I'm trying to give pointers for exactly that stage in there. Happy about feedback too if you have any (ie. does it actually answer questions, how could it do a better job, etc.) 😊 any other questions you have of course feel free to ask! cheers

@sknob it's a good question, wasn't so easy for me to decide this either. 😊 My considerations were:

1. Working in a 2.0 branch would have made it easier to do a potential 1.7.1 or 1.8 release in between on main, or do random merges in between (translations or such). Then again, dealing with potential rebase conflicts for such in-between changes could turn out very time-consuming (just the base commit for 2.0 I added today adds 20k+ and removes 10k+ lines ...). Putting the work right out there on main is a bit of a commitment to the decision that I'd rather include such changes directly into 2.0 than do costly in-between work for minor changes.

2. Likewise, putting the work on main signals to people that if they prepare elaborate PRs right now, they risk conflicts with the emerging new architecture (which might mean wasted effort), so it helps people to consider that factor.

3. Putting major development onto a branch hides that activity from easy discovery, so it definitely helps to develop out on main so people don't miss what's really going on in a project (especially the impatient folks who consider projects dead if there's not been a commit for two days in a row or so haha x))

These are about the main factors involved I'd say.