| Re: [eigen] backporting the vectorized quaternion product to 2.0 ? |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/eigen Archives
]
- To: eigen@xxxxxxxxxxxxxxxxxxx
- Subject: Re: [eigen] backporting the vectorized quaternion product to 2.0 ?
- From: Benoit Jacob <jacob.benoit.1@xxxxxxxxx>
- Date: Tue, 22 Sep 2009 12:21:51 -0400
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=yiriBvUf/bhelwjJ8VpiLucCQKTHneW/ylCFA/+7kLs=; b=pWFSbLvhl/qcrG9OeAlrECRJwCg80gtF/3OSe5pFSGMHLm7BrZYPr1DDNpxDW+zNeb 5/MXTybkH1Iy8Gutb725byKbbi0Y7+ZYx1wZhnOcqLjgw1DRzEdMd956KlAZoZbKEh7J gKGYE050oMRTDdQuPKb7Wgq0wwyvDXdWo61Ow=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=LA6tzf43Dgv9D9GKP4pzYRgpU8amQpuWFjI9/7pA8+rL9cVBPjbFqoyRaPJU9JO5Us vpRc7n6nr/pwzMThSXJlFQtlwJfXFitWnCVQLEoDlwDzJFdGeyzwE6D24PMB5L+8f005 O+JY/y4TZVBar0t/ZY91DdLSy5no9vUfHOz64=
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...
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.
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).
Benoit