incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Omar Gonzalez <>
Subject Re: Working towards a 4.9 Release Candidate
Date Wed, 05 Dec 2012 19:04:03 GMT
On Wed, Dec 5, 2012 at 10:57 AM, Justin Mclean <>wrote:

> Hi,
> > I'm not sure how this model relates since we aren't using git yet.
> The vote was to use the gitflow model now with git, as git is not fully
> supported yet that falls back to use gitflow branching model with SVN.
> See note 2 from the original vote:
> I's read that as Apache hasn't approved the use of Git yet for Flex so it
> applies.
> > I thought we agreed that for now we were doing development in develop,
> would
> > merge changes that would be released to trunk
> Again my understanding is that wouldn't fit in with the gitflow model.
> Thanks,
> Justin

Just to add a little more insight into the nvie model, which I use on all
our projects at work, making a release branch is desired because it is
assumed that master (trunk in SVN) is under the watch of a CI system such
as Jenkins. Thus, committing changes to master(trunk) is the equivalent of
producing a release. Basically, we should be aiming to have it such that
whenever a commit happens to master(trunk) then it should trigger Jenkins
running all of the scripts necessary to produce a release.

A release branch allows you to branch off of the develop branch in order to
accomplish the necessary work that is required to prepare the repository to
be in a state to be released. This would cover things like the inquiries
Justin has been making regarding which files need version numbers updated,
merging in any additional feature branches if needed and making sure all
automated testing is passing, etc.

Once the release branch is ready to go, it is then merged to master(trunk);
which should trigger the scripts that produce a release, and upon success
there it is remerged back into develop to make sure the develop branch is
updated with any changes that were required to prepare the release.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message