On Thu, Jan 11, 2018 at 08:35:51AM -0500, J William Piggott wrote:
>
>
> 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.
Well, my mistake. I have thought about "rename --julian to --ordinal"
and errx(EXIT_FAILURE, ("use --ordinal, --julian has been deprecated."));
This change is too aggressive without ReleaseNotes warning.
> 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.
Hmm... the calculation change for the old dates (<1752) is probably
not so big problem, although I can imagine that someone somewhere
depends on the current behavior. I'll think about it.
> Cal's output isn't machine friendly, I don't think. Isn't cal's
> intended audience human?
We should not use such presumptions. (And I remember emails and RHEL
reports from people who use cal(1) for research to see old dates, or
in scripts for some complex outputs, etc.)
Karel
--
Karel Zak <kzak@xxxxxxxxxx>
http://karelzak.blogspot.com
--
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
