git repo structure

[Michael Bedward]

Dear all (esp. git gurus),

At the risk of jaitools version 1.3 being forever a couple of days
away, I'd like to sort out a working structure for the repos prior to
doing the release. Two obvious candidates are (1) the GeoTools model,
with a long-lived release branch in parallel to each stable branch; or
(2) the "git-flow" model
(http://nvie.com/posts/a-successful-git-branching-model/) where
release branches are short-lived, release tags are merged into master,
and there is a long-lived development branch.

At the moment I favour (2) because it looks easier, ie. I think I'd be
less likely to cock it up.

What do you think ?

Michael

[Justin Deoliveira]

We actually recently decided to change our release model slightly for GeoTools and not have a long lived release branch. The reason being it was causing issues with our automated releases and merging. So we simplified and basically create a temporary release branch for a release, update it with version numbers, etc... and then tag it. After that we push up the tag and delete the origin branch. 

Michael

--
You received this message because you are subscribed to the Google Groups "jai-tools" group.
To post to this group, send email to jai-...@googlegroups.com.
To unsubscribe from this group, send email to jai-tools+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/jai-tools?hl=en.

--
Justin Deoliveira

OpenGeo - http://opengeo.org

Enterprise support for open source geospatial.

[Michael Bedward]

Hey Justin - so is that moving towards this git-flow model where the
release tags migrate to master ?

Michael

[Michael Bedward]

On a little more reflection, perhaps projects as small as jaitools and
jiffle don't need the concept of stable branches at all. After all,
Martin has been running JTS that way for a long time. When JTS 1.12
was released there was no 1.11.x branch in his svn repo for
maintenance.

The equivalent in git could be two permanent branches: master and
releases. Master is always the latest hacking snapshot. When a release
is due (or overdue as at present), create a temporary prep branch off
master to do final testing, bump version number etc. and then, when
happy, rebase that on to the top of the releases branch and give it a
tag.

If you can spot big problems with that approach, please let me know.
Otherwise I think I'll go with that.

Michael

[Justin Deoliveira]

On Thu, Sep 27, 2012 at 2:24 PM, Michael Bedward <michael...@gmail.com> wrote:

Hey Justin -  so is that moving towards this git-flow model where the
release tags migrate to master ?

Not quite. We never tag any of the stable branches directly, reason being we want to avoid the "everyone out of the pool" so that someone can update version numbers, etc...  Also, after discussed i figured that the changeover to git was enough of a change for the time being so felt it best to keep a release branching structure close to what we have now. I do like a model like this other projects though.

Michael

On 27 September 2012 21:46, Justin Deoliveira <jdeo...@opengeo.org> wrote:
> We actually recently decided to change our release model slightly for
> GeoTools and not have a long lived release branch. The reason being it was
> causing issues with our automated releases and merging. So we simplified and
> basically create a temporary release branch for a release, update it with
> version numbers, etc... and then tag it. After that we push up the tag and
> delete the origin branch.
>

--
You received this message because you are subscribed to the Google Groups "jai-tools" group.
To post to this group, send email to jai-...@googlegroups.com.
To unsubscribe from this group, send email to jai-tools+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/jai-tools?hl=en.