incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dave Fisher <>
Subject Re: SVN and issues with branching / consider how we use SVN going forward
Date Thu, 09 Aug 2012 15:15:56 GMT

On Aug 9, 2012, at 8:06 AM, Greg Reddin wrote:

> On Wed, Aug 8, 2012 at 6:15 PM, Dave Fisher <> wrote:
>> I totally agree. Maintaining an unstable version will actually make more work. Just
when you think it is stable enough to move into trunk, you have to make it stable again in
>> The community should be perfectly capable of deciding when trunk should be made stable
for an upcoming release and stop making ill considered changes.
> We argued about this for days at $work, then we finally stumbled on a
> solution. Flip the model around. Trunk becomes the unstable, do
> whatever you want, development branch. Create a separate stable or
> release branch where code gets "promoted" to.
> The process is still evolving. We haven't quite figured out the best
> way to "promote" code in svn. Here's what I *think* we'll move to
> pretty soon:
> 1. Trunk is still the unstable development branch.
> 2. People create feature branches for work that can't be completed in
> short order. Merge often from trunk to your feature branch.
>    2a. When feature branch is done, merge --reintegrate back to trunk.
> 3. Trunk is always pretty close to being ready to release even though
> it is considered unstable.
> 4. When we are close to a release we restrict changes on trunk to
> those related to the release.
> 5. Tag releases.
> 6. For a patch/bugfix release create a branch from the previous tag.
> Make the bugfix in the branch. Be sure to make it in trunk also
> (sometimes it's easier to make the change in trunk then merge it to
> the branch).
>    6a. Tag the patch/bugfix release
> Not fully fleshed out, but a basic plan.

That is pretty much what I do at work as well. It also fits what is done in Apache POI and
Apache OpenOffice. With Apache OpenOffice, had been recently converted from
SVN to HG (Mercurial) before the Oracle donation. There are huge workspace branches, a selected
set of these got merged to trunk. Now individuals branch for large changes. Lessons are currently
being learned with the second release, but that is mostly about not being so quick to roll
a new RC every time a showstopper is fixed in trunk. AOO is a huge codebase.


> Greg

View raw message