flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Harui <aha...@adobe.com>
Subject Re: Branch Strategy (was: So, what should we do first?)
Date Thu, 05 Jan 2012 19:13:21 GMT
OK, so to summarize (mainly for me since we did not work this way before):

Trunk is where we prep builds for release.  It can be broken (but shouldn't
be) and isn't the latest released code.

Tags will hold branches of Trunk for each release

Branches holds other branches of Trunk for more unstable things, long term
or short term when it makes sense to work in a separate branch.

Folks can use Git on their local machines, but we will only have SVN
branches in the Apache project.

Some questions:
-Should there still be a Whiteboard or Sandbox folder or is it fine to just
create those under Branches?

-If you have to fix a bug in the Tags folder, I assume you should branch
that released branch (say from v4.7 to v4.7.1) right into Tags and then make
your change?


On 1/5/12 2:23 AM, "Bertrand Delacretaz" <bdelacretaz@apache.org> wrote:

> Hi,
> 
> 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, flex@rduartes.net <flex@rduartes.net> 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
> https://builds.apache.org/ 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
> http://svn.apache.org/repos/asf/incubator/flex/ 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 TRUNK...
> 
> 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 http://svn.apache.org/repos/asf/sling/whiteboard/ 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
> http://git.apache.org/ - 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.
> 
> -Bertrand

-- 
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui


Mime
View raw message