On Mon, 3 Oct 2011 18:20:35 +0200 Jiří Techet techet@gmail.com wrote:
- 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.
Here I need to disagree. I think its a good idea to have a separate releases branch. Its not a big effort to maintain it and will allow users to build releases direct from git more easily.
- 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.
I agree. There is no real need to have release branches always and in every cases. They can be created on demand from every parent.
- 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.
Sounds reasonable.
Cheers, Frank