I would like to start the 9.x release branch early as uDig will be making
use of milestone releases.
--
Jody Garnett
On 30/06/2012, at 12:00 PM, Justin Deoliveira <jdeol...@opengeo.org> wrote:
Hi all,
With the transition to git I have been thinking about how to manage
branches/tags/etc... with respect to releases. Here are my thoughts, which
i believe are consistent with the up and coming move to a time-boxed
release process.
Because I love diagrams here is a diagram as to what I think this will look
like.
<image.png>
In case that doesn't show up for folks here is a direct link:
http://www.evernote.com/shard/s222/sh/2d02d6ba-46a5-475f-a990-a9c453b75a95/f25456903515efc31d51b39e2df23fc9
So the gist of it is that most of the time we have 2-3 (usually 2) active
branches:
1. master - unstable, under active development, equivalent of what was
trunk
2. n.x -> stable, under active "stable" developer
3. (n-1).x -> previous stable, being phased out
For each stable branch we also maintain a release branch that releases are
cut from. These branches are tagged for individual releases. At any given
point in time the state of this branch is the latest stable release in that
series. My rationale for maintaining a separate release branch is mostly
because during releases we modify the actual branch to change version
numbers, update README, etc.. Without a release branch we would have to do
this on the main stable branch which would mean would have to ask people to
"get out of the pool", which we have just recently worked to avoid with a
lighter weight release process that involves grabbing a single revision and
releasing from it.
So basically when doing a release the workflow at a high level is:
* checkout the release branch
* merge with the parent stable branch up until the revision to be released
* update version numbers, etc...
* tag
* push branch and tag up to canonical
An alternative to long lived single release branch would be multiple short
lived release branches, one for each release, rel_8.0, rel_8.1, etc... I
decided against this mostly because the number of branches in
the repository will start to accumulate much faster. Also because I like
the idea of having a release branch whose state is always exactly that of
the last release.
You'll notice that in the above diagram there is no corresponding release
branch for master. This is intentional and also differs from how we do
things today in that we do sometimes cut
betas/milestones/release candidates from the trunk. We could potentially
create a release branch for master but i figured that with our new time
boxed release model and the stable cycle being shorter than in the past we
could probably get by without it.
Anyways, just some thoughts how this could look based on experiences with
other projects that use git as the main repo. But certainly open to
alternatives. I am not so up to date with udig these days... be interested
to see how they approach things. Looking at the repo i don't see any
release branches... i guess its a "everyone out of the pool" sort of thing?
-Justin
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
