[Geany-devel] Plan ahead (to fail to plan is to plan to fail)

Jiří Techet techet at xxxxx
Mon Oct 3 17:16:09 UTC 2011

On Mon, Oct 3, 2011 at 18:52, Colomban Wendling
<lists.ban at herbesfolles.org> wrote:
> Le 03/10/2011 18:20, Jiří Techet a écrit :
>> On Mon, Oct 3, 2011 at 17:29, Colomban Wendling
>> <lists.ban at herbesfolles.org> wrote:
>>> Le 03/10/2011 06:15, Lex Trotman a écrit :
>>>> [...]
>>> 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.
> Agreed, totally.  It's not like Git is expected to be the primary source
> for people wanting the release, in which case making it the default
> would maybe make sense.
>> 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.)
> Yeah, agreed too.  What I like in the blog post's workflow is that
> *every* single feature gets its own incubation branch, not only "big"
> ones.  This cleans up "master" state, and makes reading the history easier.

Even in the case of single-commit features? I completely agree with
more-than-one-commit features because otherwise you don't know where
the feature implementation starts and ends but having it for minor
one-commit features seems like overkill to me.

>> 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.
> Not completely sure.  Actually during 0.21's freeze, Nick created the
> unstable branch and worked on it.  OK, with a DVCS he could've created a
> local one (I do have one myself) and rebased it later, but OTOH, it
> prevents his changes from being seen by others.
> But one can also argue that if the development branch isn't the release,
> the release don't get as much attention as it should...
> So I don't have a strong opinion on this, both seems OK to me, yours is
> more wide spread.

I'm not against this idea completely, I just don't feel Geany needs
it. If you branch before release it adds some overhead because many
commits will go both to the release branch and to master. Anyway, new
release is far away so there's plenty of time to decide what's best
for Geany meanwhile.


More information about the Devel mailing list