incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicholas Kwiatkowski <nicho...@spoon.as>
Subject Re: So, what should we do first?
Date Thu, 05 Jan 2012 05:32:03 GMT
I would have to agree with Jeffery.  Almost all of the projects I've seen
that use SVN are organized in a Trunk/Branch/Tag method.  I don't see any
reason for us not to mimic the same.

I also think that long-term 'projects' and short-term be given the same
treatment.  Each gets its own branch, and when completed (or when it is
stable enough to be brought into the main trunk) and voted on, it is merged
into the main trunk.  When we are ready for a release (4.7, 5.0, etc), the
trunk is tagged with that version number and life goes on.

I've not worked on any projects quite this large before, but for just about
every project I have worked on some variation of this method seems to have
worked pretty well.  What is nice about it to is when working on a feature,
you really only have to concern yourself with your branch, and not about
progressing it through multiple multiple branches and merging it multiple
times.


-Nick Kwiatkowski

  Telecom Systems Engineer, Video and Voice Systems

  Michigan State University Telecommunications Systems Department



  Adjunct Professor within the Telecommunications, Information Studies and
Media Department at Michigan State University



 (t) 517-432-2528        (f) 517-353-6633       (h) 517-853-9050

From: Jeffry Houser <jeffry@dot-com-it.com>
To: flex-dev@incubator.apache.org
Cc:
Date: Wed, 04 Jan 2012 20:56:47 -0500
Subject: Re: So, what should we do first?

 I can honestly say it's been a long time since I looked at the public Flex
SVN repo; so I'm not sure the extent of what is in there or how it is
organized.

 Most projects I've worked on have used a "Trunk/Branch/Tag" approach.  To
map:

* Released sounds kind of like tags; which is a full snapshot in time
that--presumably--doesn't change.
* Stable sounds kind of like Trunk, which is the primary working branch for
the next version.
* Sandbox/Unstable sound like branch; which are different working copies.
 They often start as an off-shoot of the trunk; presumably to be combined
back in at some future point.

 Is it worthwhile to separate "long term development" (Sandbox) ) vs "Short
term stuff development" (UnStable)?  I assume we wouldn't want to do that
development in the same sub-branch; but is there a reason to make the
distinction between short term and long term development?

 Beyond that, I don't have a strong opinion either way.

On 1/4/2012 7:42 PM, Alex Harui wrote:

> I’m loving the ideas and energy on this list so far.  And so, the subject
> question needs to be answered:  What should we (the committers in this
> project) do first?
>
>
> To do so without getting de-stabilized by the longer term projects, we
> should agree on a branch strategy.  It sounds like many Apache projects
> have multiple branches like:
>     -Sandbox:  Anything that doesn’t fall over immediately can go here
>     -Unstable: Things that are being polished for release can go here
>     -Stable:  The release candidate goes here.
>     -Released:  The latest release.
>
> Long term projects would go in Sandbox and shorter term stuff would go in
> Unstable and get synched to Sandbox if required.
>
> Most of you are volunteers trying to scratch out spare time to make
> contributions, but some of us have all day to work on this stuff.  I am
> thinking of splitting time between long-term work and short term work and
> use JIRA to guide what short-term work I do.
>

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