Just to expand on what I said earlier. I am hoping we don't agree on
removing sandbox.
Sandbox is a really important working area for each person. The big thing
is that sandbox isn't just a giant dumping ground. Instead it is a giant
dumping ground per person. This was I have my section of experimental code
vs someone else. Everyone can quickly go through the various sandboxes and
see the experimental work each person has, see if they want to work on
their experiments, which will lead to the momentum to having a feature
including back in trunk.
Sandbox is especially important as we don't have a roadmap and there isn't
a direct path for people to program down. On most projects you have a focus
or agreed goal and developing branches in that direction is simple. Not the
same as what we are doing here.
On Jan 5, 2012 2:41 AM, "f...@rduartes.net"<f...@rduartes.net> wrote:
Hi,
I can safely say that I have a bit of experience using Subversion to
manage a long running project with a big development team across several
technologies and the one thing I'm pretty sure of is that, if not managed
correctly from the onset, Subversion could be a nasty beast to handle.
I'll add my suggestion in here about Subversion organization as I've been
giving it a lot of thought lately and I've come to some conclusions/ideas
that might be of interest.
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;
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. This would be important if we ever
have
(and want) to release fixes and patches for a particular version. These
branches are created from TRUNK when a voting for release is determined;
3. Every development, big or small, would be done under a feature branch
taken out of TRUNK. A feature branch per development. These feature
branches would be refreshed regularly with code from TRUNK and would be
merged back (and closed) to TRUNK when the development is finished and
ready to be integrated into the main stream after such action is voted by
the group. When different feature branches have dependencies between
them,
they should decide which would be the prime branch that would carry
changes
from both to TRUNK, this one being refreshed from the dependent branch
and
TRUNK. The dependent branch would be merged to the prime branch when it
finishes its development and the prime branch would be merged to TRUNK
when
it finishes its development (and has received all merges from the
dependent
branch);
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).
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. If we opt to not release patches to released versions, then
there's
effectively no real need to have separate release branches (though it
makes
it easier to track down bugs found in a particular version). I also
realize
that some of these ideas can be achieved by simply using revision numbers
as a tag system, but since branches are Subversion core concept for
tagging
and divergent development control, I'd use those instead.
Just my two cents on the subject. Sooner or later we'll have to vote on
this, especially if Adobe is about to commit the source code.
Cheers,Rui
----------------------------------------
From: "Alex Harui"<aha...@adobe.com>
Sent: quinta-feira, 5 de Janeiro de 2012 7:15
To: "flex-dev@incubator.apache.org"<flex-dev@incubator.apache.org>
Subject: Re: So, what should we do first?
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" 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" 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
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
