Tagging, releases and a problem

[Andreas Zehender]

Hi!

On Thursday 14 February 2002 20:33, CARVALHO Luis Passos wrote:
> > Should I add the pigment change to the bugfix release? Or can the
> > inconsitencies be tollerated? It's hard to maintain two versions
> > separately.
>
> You can use tags/branches in the CVS to maintain different code.
> Unless you develop in parallel in the two branches, the space needed to
> store the code doesn't increase.
> That way, if there is a serious bug you can check out that release's
> code and patch that, without messing with the HEAD development.

I don't know if we are allowed to add branches to the KDE CVS.

> Anyway, only serious crashing bugs should be fixed in alpha releases, I
> think.

That's what I did for the 0.1.1 version.

> By the way, do you have any idea on what do you intend to have working
> before the next release?
> I think I can finish every texture component before the next release
> (icons excluded :)), unless you want one real soon.
> Also, I need to go through all the includes I've written and document
> them, as most of them are not documented yet.

I want to finish all povray 3.1 objects for the next release. I am almost 
finished with the prism and lathe objects, but there are some tricky ones 
left. I have no idea at the moment how to generate a wire frame for the 
poly, cubic and quartic objects for example.

The next release will not be very soon. The 0.1 version was a usable 
version to get some user feedback. I do not plan another release except 
the bugfix release the next time.

> As for the problem:
> 	It comes from interdependencies between objects.
> 	For instance, certain pattern types are incompatible with normals or
> specifying a depth in a pattern is incompatible with slope map or
> normal map.
> 	The control for this belongs to their parent object in the tree. So,
> what I thought was, much like in pmdeclare, the type is different,
> depending on what is inserted in the declare, a pmpattern can also
> return different object types depending on it's pattern type and if
> there is a depth or not. Another possible solution is to have a
> subType() method so that the parent knows what to expect. What do you
> think?
>
> 	Personally I'm more in favor of the first, as it doesn't change
> anything in the framework, but it's less open to change than the
> sub-type approach.

One additional solution: The depth attribute is only shown by the edit 
dialog if the parent of the pattern is of a certain type. The depth value 
is only serialized by the pattern if it is allowed.

A subType method will IMHO kill the current framework. Different object 
types that are dependent on the pattern type should be no problem and the 
better solution.

Greetings, Andreas
-- 
--------------------------------------------------
 Andreas Zehender, Dipl. Ing. (BA)
 Student, 9th semester computer science
 http://www.azweb.de
 az@azweb.de | zehender@kde.org      
--------------------------------------------------