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

Frank Lanitz frank at xxxxx
Mon Oct 3 18:16:06 UTC 2011


On Mon, 3 Oct 2011 19:24:40 +0200
Jiří Techet <techet at gmail.com> wrote:

> On Mon, Oct 3, 2011 at 19:00, Frank Lanitz <frank at frank.uvena.de>
> wrote:
> > On Mon, 3 Oct 2011 18:20:35 +0200
> > Jiří Techet <techet at gmail.com> wrote:
> >
> >> 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.
> >
> > 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.
> 
> git checkout RELEASE_TAG
> ./configure; make; sudo make install
> 
> It's not that difficult.
> 
> I'm not completely against the releases branch, but I'm strongly
> against this to be "master". In addition I'm not sure how to handle
> situations when you want to release say 0.22 and few days after the
> last maintenance release of 0.21. e.g. 0.21.3 - those two will
> conflict badly.

Wasn't thinking about to make it as master. But the last point you
mentioned is correct. We should really only use tags on master or
inside maintenance branches. 

Cheers, 
Frank 
-- 
http://frank.uvena.de/en/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.geany.org/pipermail/devel/attachments/20111003/751b7a9a/attachment.pgp>


More information about the Devel mailing list