On Mon, Oct 3, 2011 at 17:29, Colomban Wendling lists.ban@herbesfolles.org wrote:
Le 03/10/2011 06:15, Lex Trotman a écrit :
Hi All,
Now we have 0.21 released I thought it was worthwhile looking at the path ahead, and since we have the possibility of some quite significant changes, maybe starting a plan of attack so that not too much effort is wasted.
The big things I see right now that have had some work are:
- change to DVCS and hosting, and possible changes to process that
forces/enables (to my mind the process issues are more important than the DVCS itself)
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"
change to Glade 3 (entails GTK change)
support for GTK3 (needs above and might entail a further GTK change)
support for plugins in non-C, non-compiled languages (as full
plugins, and the VM/interpretor as a plugin itself so core doesn't need to be changed to add more languages)
session support (has been sitting in a branch for a while)
patches in the queue (some are getting a bit old)
bugfixes
Seems reasonable as future plans, not sure all would fit in a single release... well, we'll see how fast things goes anyway :)
- call it 1.0
Or 1.22, it's what is in SVN now.
roughly from the most disruptive to least disruptive.
Then there are all the bright new things that will inevitably come up :)
My main suggestion is that it would be best to do the change to the VCS first, then it won't disrupt the other things. And get the process bedded down (stable branch, develop branch, version branches ...) and call that 1.0.
Agreed with the strong branching scheme, http://nvie.com/posts/a-successful-git-branching-model/ feels good to me.
I just went through the blog post and I must say I disagree with more things than I agree:
1. The split between master and develop is completely unnecessary. I don't see a reason why there should be a separate branch for releases (i.e. commits with tags). The post says that a merge to master is a release by definition. I prefer to do things the way everyone else does them - a commit with a tag is a release by definition. Moreover, everyone expects master is the trunk so I can imagine people will be really confused when they clone a repository and build Geany from sources because master in the above model is a dead space between releases.
2. I agree with non-fast-forward merges of feature branches. These branches however have to be real feature branches where work concentrates on implementing a single feature (e.g. GTK 3 support). For instance I have a branch for_review with random bugfixes and minor features which shouldn't be treated as a feature branch and which can even be rebased on top of master (If you have a look at GTK, you see only a small number of merges - with bugfix-like commits there's very small danger that someone else bases work on them.)
3. I wouldn't make release branches before the actual release - I think having releases directly on master is just fine. This means some slowdown in development but individual developers will have their feature branches where they can continue working and which will be merged to master after the release anyway. Geany isn't a project with such a wild development it should cause any trouble. Maintenance branch for a dot release can be created immediately after the release commit before post-release version increment.
4. Hotfix branches: if a fix is a single commit, it can be directly applied to master and cherry-picked to maintenance branch. If the fix is more of a feature-branch nature, the feature branch for the fix can be created and once finished, it can be merged both to master and to the maintenance branch.
This means the workflow I suggest is very similar to the present workflow; actually I believe it's the workflow used by most projects and the most common-sense one. I'm afraid I'd get quickly lost in the workflow suggested by the blog post and I don't see real benefit for Geany with such a workflow.
Cheers, Jiri