[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Fenfire-dev] 7 projects to one big branch?

From: Janne Kujala
Subject: Re: [Fenfire-dev] 7 projects to one big branch?
Date: Fri, 16 Jul 2004 21:14:12 +0300
User-agent: Mutt/1.4.1i

On Fri, Jul 16, 2004 at 06:46:50PM +0200, Benja Fallenstein wrote:
> Janne Kujala wrote:
> >You can do that in Loom and move the code to Libvob once
> >it is stable enough to be useful elsewhere.
> But then it's code that is in the wrong place, which means code clutter. 
> This is even worse when it's adding features to an existing class, i.e. 
> introducing a copy-and-pased second version. What's the gain from this? 
> Theoretical cleanliness. What does it cost? Practical cleanliness. I'm 
> not willing to give up the latter for the former.

Not all such cases are code in the wrong place.
E.g., a special vob for some special application belongs
to the project of that special application, until it is generalized.

I am not suggesting copy-paste code. If it really is often
inconvenient to first make the changes to Libvob independently
of the dependent project, then we should have the two
projects in one branch.

> >And there are stable parts of Libvob that should be in Libvob.
> Such as?

The vector classes in Vec23.hxx.
Also, the underlying template framwork making it all 
work toghether is rather stable.

> >Changes are either added features or backward incompatible.
> >Backward incompatible changes are the only changes that require
> >atomic commits in order to have everything always compile.
> Nonsense. When you add features, you cannot roll back the independent 
> project without rolling back the dependent project if you want the 
> dependent project to compile.

A rollback of the independent project is a backward incompatible 


reply via email to

[Prev in Thread] Current Thread [Next in Thread]