[...] > Yep -- though I think I'm missing something ti your sentence... I don't > get the meaning of "and possible changes to process that forces/enables" >
Apologies for the inelegant language. You said it yourself below :), I meant things like using branches and committing to develop not master etc. [...] > > Seems reasonable as future plans, not sure all would fit in a single > release... well, we'll see how fast things goes anyway :) > Sure see how we go, but on Geany's usual release cycle it would be long time to wait if they don't fit this cycle. >> >> 8. call it 1.0 > > Or 1.22, it's what is in SVN now. Ok. Anything to avoid another doodle please :) > [...]> > Agreed with the strong branching scheme, > http://nvie.com/posts/a-successful-git-branching-model/ feels good to me. Agree. > >> And then other disruptive things can then be done in repository forks >> so they don't get too much in each others way. > > And/or feature-branches ;) For big changes I'd say start with a fork where the dev and friends can mess around to their hearts content until it seems to work, then make a feature branch as it moves towards usability and you want more people to test and QA it and have it a bit more community controlled and then merge with develop as it is accepted. Small changes/bugfixes make in a fork until it works and send Colomban a pull request to put it in develop or send him patches. Cheers Lex _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel