[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 19:19:51 +0300
User-agent: Mutt/1.4.1i

On Fri, Jul 16, 2004 at 01:46:37PM +0200, Benja Fallenstein wrote:
> >Perhaps you should first implement the new vob in Libvob,
> >write tests, debug it, and only then use it in Loom. 
> I prefer coding being driven by actual needs, rather than creating
> interfaces and classes &c in thin air and later discovering that they
> don't actually do what is needed. It's more fun, too. And that's
> important, too :-)

You can do that in Loom and move the code to Libvob once
it is stable enough to be useful elsewhere.

> Well, with that logic, all of Libvob could be in the Fenfire project, 
> because it's not used anywhere except in Fenfire at the moment.

It is used elsewhere, e.g., the color experiment stuff uses Libvob.
And there are stable parts of Libvob that should be in Libvob.
All of Callgl is stable; there haven't been any backward 
incompatible changes for a long time.

> The point is to make it *possible* to use it independently.

It can be done as soon as some stability is reached.

> >There's no problem in adding new features; they (usually) do not
> >break anything.
> I don't think that there's a problem with changing existing interfaces 
> to make them better, either, as long as the code using it is updated so 
> that it continues to work.
> But the question was whether commits should be atomic, not sure what 
> this has to do with it.

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.

> The usual scenario is that you want to undo a change done in the last 
> few days, either because you don't like it or because it introduced a 
> bug. In both cases, you would usually want to roll back both projects, 
> I'd think.

In that case, it would have been better to have the unstable code
only in the dependent project.

> I don't agree, because NONE of our code is stable enough that we can 
> guarantee that code depending on it doens't need to be changed. Our code 
> *can* be used by code that *can* be changed when our code changes, of 
> course.

Such changes are fine as long as they don't happen too often.

I'm saying that interrelated fragments of unstable code 
(particularly new code) do not necessarily need to cross
project boundaries. 


reply via email to

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