--- On Tue, 5/4/10, Jacopo Cappellato <jacopo.cappell...@hotwaxmedia.com> wrote:
> On May 4, 2010, at 6:17 PM, Adrian Crum wrote:
>
> > I'm confused. What do you mean by "a more stable
> framework?" Is the framework currently unstable?
>
> I should have said probably "a more static framework"
Okay, that makes sense.
> > What do you mean by "more dynamic applications?"
>
> This doesn't make a lot of sense, I was probably just
> tired.
> My proposal was addressed in having a more severe policy in
> the commits that change the features of the framework but
> let the applications features set grows freely.
> This is why I suggested to commit the new features for the
> framework in a separate branch, test it, and then merge back
> in a scheduled way.
I would support any effort to add more control to the framework. I support
having many committers involved in the framework (so it doesn't become
stagnant), but at the same time it would be nice to have better control over
framework releases (so it can be reliable). David's suggestion of a separate
branch for the framework is an excellent idea.
-Adrian
> > On 5/4/2010 12:04 AM, Jacopo Cappellato wrote:
> >> What if we start evaluating a different way we
> organize our svn, daily work and release strategy?
> >> We may try to move in the direction of having a
> more stable framework and more dynamic applications.
> >>
> >> A very simple strategy would be the following
> one:
> >>
> >> all the changes to the framework (that are not bug
> fixes) are done in a separate branch
> (branches/framework-latest or similar); in this way
> trunk/framework will only get bug fixes.
> >> Every 6-12 months (or whenever we want - we can
> discuss about this) we merge the branches/framework-latest
> into trunk/framework and fix the trunk/applications (of
> course we could do this in a separate temporary branch).
> >>
> >> What do you think?
> >>
> >> Jacopo
> >>
> >>
>
>
