tor, 22 12 2011 kl. 09:47 -0500, skrev Jordi Gutiérrez Hermoso: > 2011/12/22 Søren Hauberg <so...@hauberg.org>: > > tor, 22 12 2011 kl. 09:24 -0500, skrev Jordi Gutiérrez Hermoso: > >> On 22 December 2011 07:33, Arno Onken <asn...@asnelt.org> wrote: > >> > >> > Should kmeans be backward compatible with 3.2.4? > >> > >> I don't think it should be. And Søren's fix to replace [~, foo] = > >> bar() with [tmp, foo] = bar() isn't quite equivalent. Although I don't > >> think min does this, a function can know if an output parameter was > >> requested or not and avoid computing it if it wasn't. > > > > I really don't think this type of performance tweaks makes much (if any) > > difference in real life. > > No, not in this case, agreed, but I just think that in general > matching Octave-Forge development to the abilities of some packaged > version of Octave isn't the best idea.
I agree with that statement, but (to me) the keyword here is "packaged". Had you instead said "released", or something similar, I would have disagreed. I do not see the point in trying to explicitly prevent users of old Octave versions from using new Octave-Forge packages. From a Debian (or any other distribution) point of view, everything you say makes perfect sense. I just wouldn't be surprised if some users (Windows users come to mind) still use 3.2.x, but would like to use more recent packages. Since it doesn't seem to hurt us to allow them to do so, I guess I just don't see the point in explicitly ensuring that a function does not work with 3.2.x. Of course, if the change had any impact on performance or similar, I would feel differently. > If I had it my way, we could have Octave-Forge development branches > that matched Octave's branches, so if you really wanted to support an > old version of Octave, you could do so in a separate branch and use > current features of Octave in your main development branch. The problem is that this assumes that Octave-Forge is coordinated effort (I think). I have always thought of it as a collection of (more or less) independently developed packages with many maintainers. So, I think it would be hard to achieve what you are suggesting. That being said, we agree that more coordination between the projects would be a good thing. Cheers Søren ------------------------------------------------------------------------------ Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev _______________________________________________ Octave-dev mailing list Octave-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/octave-dev
