On Sat, Jun 30, 2012 at 3:59 AM, Justin Deoliveira <jdeol...@opengeo.org>wrote:
>
> 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.
>
Makes sense, a few observations and questions.
Master wise, if we want to release a milestone, we just tag the master?
However this will require a "out of the pool"
period, even if a small one.
Branch release wise, that seems to work as well, I agree having a ton of
little branches on github will
make using the github GUI hard (especially for newcomers) and will leave
people wondering why
in the world we have branches that look like tags.
At the same time the release branch is sort of a technicality, isn't it? Is
there a way to make it "non advertised"
on github?
I'm also considering the new automated release process, may there be issues
using this branch
model automation wise?
Assuming we have automation I guess another possible way is to have the
script make the changes
on the stable branch, commit, then commit a revert of those, and then tag
the specific revision number
that had the version number changes as the release... convoluted enough? :-p
Cheers
Andrea
--
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 962313
mob: +39 339 8844549
http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf
------------------------------------------------------------------------------
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
