Re: [eigen] backporting the vectorized quaternion product to 2.0 ?

[Rohit Garg <rpg.314@xxxxxxxxx>]

On Tue, Sep 22, 2009 at 9:51 PM, Benoit Jacob <jacob.benoit.1@xxxxxxxxx> wrote:
> 2009/9/22 Rohit Garg <rpg.314@xxxxxxxxx>:
>>> Rationale:
>>> 1) it's not dangerous as long as it's covered by a unit test
>>> 2) it's a cool feature and as the next major version takes a long time
>>> to prepare, it's nice to backport some cool features.
>>
>> I suggest that eigen should adopt a quick release philosophy. The gap
>> between 2.0 and the devel branch is now too much. It is fun to code on
>> the devel branch, but it is likely that such need for backports will
>> only increase. While a kernel style release system is out of the
>> question, I would certainly suggest that we move towards incremental
>> releases to avoid doing the same work 1.5 times.
>>
>> What is the release criteria for branching off 2.1 anyway?
>
> The thing is, initially we expected 2.1 to be just a compatible
> feature release, and i was expecting to release it 6 months after 2.0.
>
> Then it turned out (very quickly) that there were important reasons to
> break compatibility. And in the process, big re-designs of the API
> started to appear useful.
>
> The development branch is now already too incompatible with the 2.0
> branch to be just called "2.1", i'm afraid. And it's only getting
> worse with upcoming changes such as the solve() API refactoring.
> Ideally, we'd only call it 2.1 if it's a drop-in replacement for 2.0.
>
> The truth is that we're learning matrix algorithms as we develop
> Eigen, so perhaps it wasn't realistic, one year ago, to claim to
> finalize the API when actually we were just learning about matrix
> algorithms.
>
> I would like to advocate this plan, feel free to object: let's take
> all our time with this new version, and let's do all the changes that
> are needed, until we have a rock solid API. Then we release the result
> as Eigen 3.0, installing with prefix eigen3/ so it's co-installable.
> After than, since we have a rock solid API, we can do compatible point
> releases, 3.1, 3.2...

3.0 sounds better. Apart from API, what else do you plan to put in 3.0?
>
> We are well on our way already, and I think it's realistic to aim for
> a beta in 3 or 4 months, with a near-finalized API, and final release
> in Q2 2010.

I think it is important to setup the features spec for 3.0 now and
stick to it. Otherwise we'll suffer from feature creep. Since the gap
has been long, I suggest that we keep the API changes for 3.0. We
don't need to make 3.0 block for sparse module since it wasn't in 2.0.
Also, it is unlikely that we'll get the sparse API right the first
time, so let's not throw the entire kitchen sink of sparse module at
it.
>
> It was just too optimistic to believe that we could get the API right
> on the first try (Eigen 2.0 was the first try, since Eigen 1.0 was a
> joke).

Yeah, that usually happens, :P
>
> Benoit
>
>
>



-- 
Rohit Garg

http://rpg-314.blogspot.com/

Senior Undergraduate
Department of Physics
Indian Institute of Technology
Bombay