[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: image 2.4.0 released
Re: image 2.4.0 released
Wed, 8 Apr 2015 12:58:33 +0100
On 8 April 2015 at 06:05, Daniel <address@hidden> wrote:
> On Mon, Apr 6, 2015 at 12:52 PM, Carnë Draug <address@hidden> wrote:
>> Hi everyone
>> a new release of the image package  is out, version 2.4.0, by Carnë
>> A summary of important user-visible changes is also available online .
>> The image package provides functions for image processing, including
>> feature extraction, image statistics, spatial and geometric
>> morphological operations, linear filtering, and much more.
>> Enjoy Octave responsibly,
>>  http://octave.sourceforge.net/image/
>>  http://octave.sourceforge.net/image/NEWS.html
> I am asking because I am interested in knowing the proper/right way of
> studying programming/organization.
> I am trying to understand how Octave source and packages organized in
> general. I have a very basic question, for example,
> The image 2.4 package news mentioned "* The image package is no longer
> dependent on the signal package."
> If I want to know what changes resulted in the elimination of the
> dependency, where shall I start?
> I would think of looking into the differences of the source between image2.4
> and previous version.
> But I am not sure if this is the best way to do it. Even yes, how shall I do
> Is there any specific tools that I can use?
> I can only think of using diff/vimdiff to check each files.
You can use "hg blame" on the NEWS file to see the commit that added that note
to the NEWS file. If things were done right, either:
1) that's the same commit that dropped the dependency on signal. It may
be possible that there are other changes before that one which led to it,
and that this one was just the last dependency.
2) that commit only added the note to the NEWS file but will at least
explain on the commit message what happened.
Those details are not on the NEWS file because the point of such file is
to list user-visible changes. According to the GNU guidelines  "a file
named NEWS which contains a list of user-visible changes worth mentioning".
The internals of changes would go on a ChangeLog file (which I don't bother
with creating but would be something like a dump of the mercurial logs).
For example, there's no point in explaining in a NEWS file that you fixed
typos on the documentation or other changes that happen behind the scenes.
This only adds noise to the message. What the user cares are the changes
facing him, i.e., faster or slower performance for specific inputs, or
causing different results.