incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bertrand Delacretaz <>
Subject Re: So, what should we do first?
Date Thu, 05 Jan 2012 10:23:00 GMT

I'll comment on Rui's detailed description, as it's the closest to
what I've seen in other Apache projects, large and small, and I think
it might work well for Flex.

On Thu, Jan 5, 2012 at 9:54 AM, <> wrote:
> ...1. I'd use a main TRUNK branch that would hold a releasable version of the project.
If we are to implement the concept of nightly builds, I'd say they come out of this main branch;..

Works for me, and for nightly builds there's which I hope Flex will use.

> 2. I'd still create a separate branch for each released version grouped in a RELEASED
or TAGS branch. We would end up having something like this: /released/v4.7 and /released/v5.0...

I already created a standard trunk/tags/branches under for now, usually I'd
put tags right under /tags, but it's perfectly ok to have
/tags/releases/v4.7 etc. as well, probably clearer.

> ...These branches are created from TRUNK when a voting for release is determined...

Sounds good.

> 3. Every development, big or small, would be done under a feature branch taken out of

I wouldn't be religious on that, rather say "it's often a good idea to
create a branch for feature work".

Assuming the trunk has serious unit tests, a lot of work could happen
right there - and people should feel free to kick someone out to their
own branch if their work starts being too big or too intrusive. But do
it only when really needed.

> ...4. Bug fixing for bugs found in a particular version would be done in that version's
RELEASE branch, or a sub-branch thereof and then merged upwards to TRUNK (and to any released
versions if we determine its important enough to have it fixed in those - I'm thinking security
bugs for instance)....

Sounds good.

> I believe that using feature branches, we can have long running developments without
having the need for a generic long term SANDBOX branch that can very easily get polluted if
we decide not to carry something to TRUNK...

I think some experimentation zone is needed, it's often called
"whiteboard" in projects that I'm involved in but "sandbox" is fine as
well (though in svn terms sandbox means your local checkout). It's not
a branch in my view, just a separate folder in svn.

See for example -
there are some folders named after committers (meant as one's personal
area, but others are welcome to commit there as well after asking,
let's not build walls), there's some redundant stuff there, or
abandoned stuff - doesn't matter, storage bytes are cheap today. Some
cleanup is needed from time to time, but there's no expectations of
any sort about what's there, and it's much better for everyone's
experiment to be visible to all. When the whiteboard stuff moves to
trunk, it's often completely rewritten, or integrated via patches.

Note that people can also work with git in parallel, see - but one should be careful to share what they
do here and in svn, and avoid working in their own corner for months,
IMO. Commit early, commit often, in a way that's visible on this list.


View raw message