[...]
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.
- 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