Hi,
Anything but option 1 from me.
Option 1 as suggested by Alex to use a single unstable branch is not considered
best practice.
Apache's SVN own docs
(http://svn.apache.org/repos/asf/subversion/trunk/doc/user/svn-best-practices.html)
give three options:
1. Never branch and work in trunk
2.
1
I love the idea of having the trunk always available to ship. Makes the
testing and QA process a lot smoother, IMHO.
-Nick
On Wed, Aug 8, 2012 at 11:33 AM, Alex Harui wrote:
> Hi Folks,
>
> I have proposed using an interim unstable branch for changes, reserving
> trunk for stuff we’re sure
On 8/8/12 11:04 AM, "Om" wrote:
> What exactly does 'for now' mean in the option 1?
>
> Is it in terms of time or releases? If we are not clear about this, we are
> only creating conflicts and confusions for us down the road.
I meant that we will use unstable until enough of us can be convinc
What exactly does 'for now' mean in the option 1?
Is it in terms of time or releases? If we are not clear about this, we are
only creating conflicts and confusions for us down the road.
I want to support option 1 until everyone has a reasonable understanding
of the complexity of the codebase.
O
1.
And I think it's very important to get to the point where we have a test suite
that we can use to ensure that trunk is ready-to-ship at all times.
- Gordon
-Original Message-
From: Alex Harui [mailto:aha...@adobe.com]
Sent: Wednesday, August 08, 2012 8:33 AM
To: flex-dev@incubator.
On 8/8/12 1 :53PM, "Jason Moore" wrote:
>The way I've used SVN before is to make the trunk the "unstable"
>development and then branch off "stable" versions. Means you always
>have a latest stable branch you can maintain / apply patches, while the
>trunk forges ahead. Branch another version of
The way I've used SVN before is to make the trunk the "unstable"
development and then branch off "stable" versions. Means you always
have a latest stable branch you can maintain / apply patches, while the
trunk forges ahead. Branch another version off the trunk when it has
progressed, then work on
1
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
P.S. I would like everybody to know that as of this morning I broke my
personal record for days lived.
1 (no binding)
João Fernandes
On Wed, Aug 8, 2012 at 10:47 AM, Peter Elst wrote:
> 1
>
> IMHO seems like a better practice and make it a more formal workflow for
> getting things into the trunk.
>
version 1
--
Jonathan Campos
1
IMHO seems like a better practice and make it a more formal workflow for
getting things into the trunk.
- Peter
1 (non binding)
On Wed, Aug 8, 2012 at 5:40 PM, Kéven Boily wrote:
> The way I see it branches should be used by a dedicated dev (or group) for
> one new feature/bugfix that's still in developpement or not completely
> implemented (incomplete). When they are done they are merged into the
> (uns
1
A thousand times: 1
The way I see it branches should be used by a dedicated dev (or group) for
one new feature/bugfix that's still in developpement or not completely
implemented (incomplete). When they are done they are merged into the
(unstable, untested) trunk. Any released version outside the trunk (not
necessarely
1
[I've been following the thread w/o having a solution to offer; at
some point I guess we'll want to document what we consider releasable code]
On 8/8/2012 11:33 AM, Alex Harui wrote:
Hi Folks,
I have proposed using an interim unstable branch for changes, reserving trunk
for stuff we’re
2
On Wed, Aug 8, 2012 at 10:33 AM, Alex Harui wrote:
> Hi Folks,
>
> I have proposed using an interim unstable branch for changes, reserving trunk
> for stuff we’re sure we want to ship, and keeping trunk “ready-to-ship” at
> all times. Others (and other projects at Apache) prefer working dire
16 matches
Mail list logo
