[Framework-Team] Re: getting rid of goldegg branch
kapil at cignex.com
Wed Oct 5 00:44:44 UTC 2005
Alec Mitchell wrote:
> On Monday 03 October 2005 04:46 pm, Michel Pelletier wrote:
>>Kapil Thangavelu wrote:
>>>i'd like to get rid of it, since it doesn't really to serve any useful
>>>purpose having this work separate from the trunk, outside of potentially
>>>making merging headaches latter. right now outside of goldegg all the
>>>development work is being done on the 2.1 branch, so its seems alot
>>>easier to just do the work directly on trunk. i'd suggest we merge plone
>>>goldegg branch to trunk, and start merging selected items back from the
>>>2.1 branch to trunk.
>>I'm +1 on this after talking about to Sidnei who is also for it. Kapil,
>>are you willing to do the merging? I'm woefully ignorant of these things.
> I think that trunk may be out of date. I was under the impression that the
> policy for plone's trunk was that it contains a snapshot of the last released
> version, rather than being a place for active development. Perhaps it would
> be better to copy 2.1 branch or trunk into a 2.2 branch and merge the goldegg
> stuff in there. I'm all for this, as long as the goldegg stuff is currently
> in a working state with all tests passing. In general, I think we should
> avoid developing new features directly on the main release branch; instead,
> we should be developing new functionality on dedicated branches and merging
> it into the main branch when it becomes stable. However, this is all policy
> stuff to be determined by the 2.2 release manager, whoever he/she is.
till right now, the plone project has never really done two major
concurrent development branches, afaicr. the trunk policy typically is
that after a release branch is finalized, its merged back to trunk and
dev work continues there for a while till a new release branch is cut
and stabilization work ensues. reality is that new development continues
on the release branch, but thats never been a goal, imho. and its never
been a policy to treat the trunk as tag archive of a release branch.
with regards to feature development branches, long lived branches with
major changes are always a signifigant risk, that should be avoided. the
work on views would be such a branch, in that even though its fairly
repetitive work of a known difficulty, there is alot of to be done, but
that work can be done on a incremental basis without disturbing the
overall state of the system, which is why i feel its appropriate for
merging to the trunk.
regardless any concurrent development, needs to constantly (and
carefully ;-) ) be merging from the 2.1 branch where alot of bug fixes
are currently directed.
i agree though that in general developing new features on the branches
is a good idea, and i'm going to branch for the cmf-2.0 integration
work, i've got sitting up my laptop, but in the case of views, i think
its more beneficial in light of the amount of low risk work, and the
merging requirements, to remove the development barrier.
we're still a few months out i think from being able to branch 2.2 and
start work on release stabilization and migrations. on a separate note,
i'd like to target a 6 month release schedule in line with zope, which
would aim towards next april as a release date, with release branching
end of january/february.
More information about the Framework-Team