[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
change.
Janne