[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: Benja Fallenstein
Subject: Re: [Fenfire-dev] 7 projects to one big branch?
Date: Fri, 16 Jul 2004 20:30:53 +0200
User-agent: Mozilla Thunderbird 0.7.1 (X11/20040708)

Janne Kujala wrote:
On Fri, Jul 16, 2004 at 06:46:50PM +0200, Benja Fallenstein wrote:
Janne Kujala wrote:
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.

Ok. If it's not generalized it doesn't depend in Libvob, agreed.

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.

Hmmm... maybe we should stay with the status quo for now and look out for situations like this in the future, to collect some real-world data about what the usual cases are =)

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.

Ah, them C++ stuff ;-)  ...  should learn C++ and read that code... ;-)

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.

Awwww, definitions! :-) It wouldn't occur to me to define things like that, but if you do, I guess I have to grant your point ;-)

- Benja

reply via email to

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