Hi All,
Gerrit Voss wrote:
>>>>> I agree with this statement and it scares me quite a bit. The 1.x and
>>>>> 2.0 code branches are diverging and I don't see an end to it in sight.
>>>>> IMHO we have to find a way to end the 1.x series otherwise the 2.0
>>>>> series will never really get going.
>> Diverging may be an understatement.
>
> It is not as bad as it sounds.
That's the optimist's way of looking at it. ;) I somewhat agree with it,
though,
the changes in 1 are mostly minor.
> Which in particular ??, we do not merge on a regular basis but usually
> all these minor fixes get pulled over once we merge (as far as they
> apply). Also some things inside 1.x need to be redesigned before they
> end up in 2.x as the current 1.x implementation is more than ugly ;-).
Anything in particular?
>>> Note: I don't speak for the OpenSG team. I may commit code once in a
>>> while, but I am not a core developer. I proposed August as a time for
>>> an alpha 2.0 because we are already using it and it seems at least alpha
>>> quality to me. ;)
>
> Kind of agree, but there is a roadblock ;-(, the pieces that are there
> are close to alpha, there should be some cleanup but August could be a
> reasonable time frame for an alpha iff we finally manage decide on the
> pointer stuff ASAP.
>
> Both implementations are there and running. Dirk wanted to work on it a
> while back but I don't have any feedback on the status right now.
Haven't gotten around to it. :( I want to do it, but other things seemt o get
into the way big time. :( :(
> We both are in favor of using plain C pointers (IIRC) the only thing we
> could not really agree on was the use of RefPointer. I'm more cautious
> when using them internally and Dirk is more in favor of using them
> internally. But actually I'm ok with both as long as the performance
> does not decrease and I don't have to implement them ;-).
:) AFAIR you were primarily worried about overhead when passing them around,
and
when using them in growing vectors. There was some discussion on boost about
moving vs. copying constructors a bit back, so I think the general problem is
understood. I think we can solve it by having an auto_ptr equivalent to pass
stuff around without refcount impact.
The benefits I am hoping to get is simplified code, especially when it comes to
parents and remembering where to increase/decrease refs. For the parents I
would
add a new FieldType that handles the parent linking/unlinking, and use that
instead of the normal MFFCPtr.
> So if we agree on C pointer I could go ahead and remove the fcptr
> pointer code along with the mixin cleanup I did a while back. Once we
> have this part out of the way we can go ahead and look into the ref
> pointer problem.
One of my goals with CPtr was to seriously simplify the code, which is why I
wanted to do it myself. If you could turn your head/hat inside out and look at
it with the KISS view instead of the elegance view I would be very happy if you
could move on that one a little bit.
> s***, I am a core developer ;-).
Ouch! How did that happen? Does it hurt? ;)
> But 99% of my time I'm concerned about
> 2.x so I basically don't do any 1.x development anymore and
> intentionally left the 1.x release to Dirk and Andreas (sorry ;-)).
That's ok, it was not your problem.
> So for me 1.x is already dead and buried and I did not follow the
> discussion why 1.8 was not released yet, so I have no idea why it
> is delayed.
I didn't push it hard enough, plain and simple. I did a few attempts to get it
out, but I didn't push it hard enough.
Thanks to the DB making an actual release is not that big a deal, it's
essentially just changing the rev number and waiting a day for everything to be
built. It would be nice to have a MacOS db, so that we could have a MacOS dist,
too...
The main problem for me is that we need people to test everything to make sure
all the installers/dists actually work as expected. I tried to launch people to
test them two or three times, but I never got a single response from anybody.
Given that I'm not optimistic enough to believe that everything is just working
that meant nobody tried it, and that's not good enough to release.
So here's a new idea: we officially go into feature freeze on 1.8 now. I'll set
up a page on the Wiki with a list of things that need to be tested and I'll ask
users and core to pick one to try, and once it works, to strike it out on the
page. Once everything is done we release. I might need some help in setting up
the list of things to test before I push it out.
Comments?
Dirk
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Opensg-core mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensg-core
