Re: [v3 PATCH 00/11] Pull Request - changelog

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On 01/11/2018 04:01 AM, Karel Zak wrote:
> On Wed, Jan 10, 2018 at 09:00:23PM -0500, J William Piggott wrote:
>>
>>
>> On 01/08/2018 05:21 AM, Karel Zak wrote:
>>> On Tue, Jan 02, 2018 at 09:53:18AM -0500, J William Piggott wrote:
>>>
>>> I have no clue how many users care and read our ReleaseNotes, but
>>> important is that they have opportunity to do that and they have
>>> always time to adopt to changes. This is how I promised that this 
>>> project will be maintained. 
>>
>> Your response here puzzled me, because I could not remember you ever
>> making a pre-announcement of this nature before.
> 
> 2.14  The losetup(8) '-s' option (introduced by util-linux-ng-2.13) is deprecated
> 2.21  The udev compatible output (-o udev) from blkid(8) is deprecated.
> 2.25  The "swapon --summary" output format is deprecated ...
> 
> ... and many warnings about commands (mkfs, tailf, mount, last, ...) and
> features (cryptoloop).
> 
> The command line options are our API, we don't do such changes often.
> 
> I remember only one exception -- sfdisk, after rewrite some obscure
> DOS-era options have been removed.

We're not talking about deprecating anything, which is why I said "of
this nature". We're not changing any API or removing any options. We're
talking about changing the default output format. As was done to hwclock
without any advanced warning and, so far, without any complaints. I
could not find any past releases giving advanced warnings for changing a
default configuration.

I really expected someone to complain that we broke their script with
the hwclock change. I think it far more likely that hwclock's output be
used programmatically then cal's. If I wanted calendar related data in a
script I'd be more inclined to use date(1); it offers a lot more control
over its output. Isn't the concern for an advance warning that the
change would break the command's use programmatically? Cal's output isn't
machine friendly, I don't think. Isn't cal's intended audience human?

Anyway, it certainly doesn't hurt anything if you want to do this the
slow painful way. The end result is the same, although a bit more work.
I'm mostly trying to understand the rational, so that I know what to do
in future instances.

BTW, I also dropped 'PATCH 09/11 cal: remove the non-functional options'
from the 171229 branch.


> 
>     Karel
> 
--
To unsubscribe from this list: send the line "unsubscribe util-linux" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Netdev]     [Ethernet Bridging]     [Linux Wireless]     [Kernel Newbies]     [Security]     [Linux for Hams]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux Admin]     [Samba]

  Powered by Linux