flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Omar Gonzalez <omarg.develo...@gmail.com>
Subject Re: So, what should we do first?
Date Thu, 05 Jan 2012 07:41:46 GMT
As far as involving Git that should be up to each individual developer. Git
is very efficient at managing branches locally and contains workflows that
allow you to interface with an SVN repository while giving you the
branching freedom that a DCVS system like Git offers.

I also agree with Jeffry on how the trunk/tag/branches model fits with the
names described in the original post by Alex. The majority of the projects
I've been involved with that used SVN always used this model successfully,
but I'm open to either suggestion as long as we all have a clear
understanding of where to put code. Personally, I'll be using Git a lot,
and syncing my work to SVN however it ends up being defined.

-omar

On Wed, Jan 4, 2012 at 10:59 PM, Alex Harui <aharui@adobe.com> wrote:

> Maybe the mentors will guide us here.  I seem to have the impression that
> the trunk should always be the release.  It can never be in a state that
> isn't a certified release.  I think that may be because our "product" is
> just source code, and folks shouldn't have to navigate through tags to get
> the latest.
>
> I'm not sure I want to involve Git.  The link someone posted seems to just
> suggest that you branch downward from trunk, which is what I'm suggesting.
> However, I did like some of the naming scheme.
>
> So to revise a bit:  trunk would always be the latest released version,
> staging would be the place we ready the next released version.
> Develop would be the place short term fixes would go.
>
> The reason I am suggesting a fourth sandbox branch for longer term work is
> that I think some folks are planning to do some serious refactoring which
> could impede the progress of short term fixes if refactoring happens in the
> base classes.
>
> Me, I'd rather start over than re-factor, but that's a thread for another
> day.
>
>
> On 1/4/12 9:52 PM, "Jonathan Campos" <jonbcampos@gmail.com> wrote:
>
> > As someone that has worked with an Apache like project before I can say
> > that the sandbox approach is very very help and would prefer to keep it.
> >
> > Branches are meant to go back into the trunk eventually, however the
> > sandbox may never go into the trunk and have various crazy changes.
> >
> > It's been helpful to me before.
> > On Jan 4, 2012 11:33 PM, "Nicholas Kwiatkowski" <nicholas@spoon.as>
> wrote:
> >
> >> 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.
> >>>
> >>
>
> --
> Alex Harui
> Flex SDK Team
> Adobe Systems, Inc.
> http://blogs.adobe.com/aharui
>
>

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