Re: .. slider -- fixing R 4.2.2-only bug in as.Date.POSIXlt()
>>>>> Dirk Eddelbuettel
>>>>> on Fri, 11 Nov 2022 10:05:58 -0600 writes:
> On 10 November 2022 at 15:27, Martin Maechler wrote:
> | >>>>> Dirk Eddelbuettel
> | >>>>> on Thu, 10 Nov 2022 07:16:55 -0600 writes:
> |
> | > On 10 November 2022 at 14:04, Martin Maechler wrote:
> | > | Well, yes, inadvertently, that would be the consequence.
> | > |
> | > | But more generally, would you really want a version a version
> | > | of R 4.2.2 which is *not* R 4.2.2 but a patched version of it,
> | > | buyt not called "patched".
> | > |
> | > | I think we (R-core) would very strongly not like that..
> |
> | > Yes as that is how (minimal) patches get applied and reported in ChangeLog.
> | > Some packages (gcc, ...) fairly regularly carry patches.
> |
> | > What you propose (jump point blank to 4.2.2.patched which has not release
> | > number is really no cleaner).
> |
> | it has an svn rev number as part of R.version or
> | R.version.string
> |
> | > R.version.string
> | [1] "R version 4.2.2 Patched (2022-11-06 r83321)"
> | >
> |
> | Of course you are right, Dirk, that we *could* consider adding a
> | minor-minor patch level, conceptually 4.2.2.1 (if 4.2.2 <==> 4.2.2.0),
> | but in the past we ended up deciding that was too much
> | release/maintenance work for us.
> I know you are on Fedora and at arm's length but please read the changelog as
> to why we do what we do. Other schemes have been tried, and created trouble. Thank you.
> https://metadata.ftp-master.debian.org/changelogs//main/r/r-base/r-base_4.2.2-1_changelog
Thank you, Dirk.
(The above URL is not quite correct but it was not hard to find
the correct one.)
I can see that you want to do this.
>From the point of view of maintenance (and communicating with
users and bug reports!) this *is* far from optimal (*), but of
course Debian must have its own priorities.
Thank you anyway a lot for your debian maintenance work!!
Martin
Reply to: