Re: [R-pkg-devel] Matrix 1.7-0 to be released in March with ABI-breaking SuiteSparse update
On Wed, 10 Apr 2024, at 11:52 AM, Martin Maechler wrote:
>> Tim Taylor
>> on Wed, 10 Apr 2024 10:37:00 +0100 writes:
>
> > Hi Mikael Revisiting this. Have the plans changed for
> > 1.7-0 release?
>
> > Tim
>
> Yes. Matrix 1.7-0 *has* been on CRAN now for while
> (i.e. 'March' has remained as announced), *but*
> -- because of the ABI change and the problem it can cause for
>*some* users --
>
> we have made it 'Depends: R (>= 4.4.0)'
> i.e., you *see* the new Matrix only once you use R 4.4.0
> which has been available as "alpha" already and is now in
> "beta" already, e.g.,
>
> R version 4.4.0 beta (2024-04-10 r86393) -- "Puppy Cup"
>
>
> Best regards,
> Martin
>
> --
> Martin Maechler
> ETH Zurich and R Core Team
Thank you Martin.
Indeed, I should have dug further.
Rdevel> packageVersion("Matrix")
[1] '1.7.0'
Cheers
Tim
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Matrix 1.7-0 to be released in March with ABI-breaking SuiteSparse update
> Tim Taylor
> on Wed, 10 Apr 2024 10:37:00 +0100 writes:
> Hi Mikael Revisiting this. Have the plans changed for
> 1.7-0 release?
> Tim
Yes. Matrix 1.7-0 *has* been on CRAN now for while
(i.e. 'March' has remained as announced), *but*
-- because of the ABI change and the problem it can cause for
*some* users --
we have made it 'Depends: R (>= 4.4.0)'
i.e., you *see* the new Matrix only once you use R 4.4.0
which has been available as "alpha" already and is now in
"beta" already, e.g.,
R version 4.4.0 beta (2024-04-10 r86393) -- "Puppy Cup"
Best regards,
Martin
--
Martin Maechler
ETH Zurich and R Core Team
> On Mon, 12 Feb 2024, at 6:36 PM, Mikael Jagan wrote:
>> Dear users and binary repository maintainers,
>>
>> We are preparing Matrix version 1.7-0 for CRAN submission
>> on March 11, ahead of the spring release of R version
>> 4.4.0. The only significant change from Matrix 1.6-5 is
>> an update of the internal SuiteSparse libraries (5.10.1
>> -> 7.6.0). Unfortunately, the old and new SuiteSparse
>> versions are binary incompatible, hence so too will be
>> the old and new Matrix versions.
>>
>> A corollary is that users and binary repository
>> maintainers switching between Matrix < 1.7-0 and Matrix
>> >= 1.7-0 must rebuild _from sources_ packages that link
>> Matrix:
>>
>> > tools::package_dependencies("Matrix", which =
>> "LinkingTo", reverse = TRUE)[[1L]] [1] "ahMLE"
>> "bayesWatch" "cplm" [4] "GeneralizedWendland" "geostatsp"
>> "irlba" [7] "lme4" "mcmcsae" "OpenMx" [10] "PRIMME"
>> "PUlasso" "robustlmm" [13] "spGARCH" "TMB" "bcSeq"
>>
>> For users, that means doing, e.g.,
>>
>> install.packages("lme4", type = "source")
>>
>> but an alternative for Windows and macOS users without
>> the required tools is
>>
>> oo <- options(repos = "https://cran.r-project.org/;)
>> install.packages("Matrix") install.packages("lme4")
>> options(oo)
>>
>> where we trust CRAN to provide binaries compatible with
>> the latest Matrix version (because we notify CRAN upon
>> submission about required rebuilds). Once other
>> repositories react with rebuilds, they can be used
>> instead of CRAN.
>>
>> Our reverse dependency checks (and history, intuition,
>> ...) show that most problems (caught segfaults in this
>> case) can be traced to a binary incompatible lme4 and not
>> to one of the other packages linking Matrix. Still, we
>> recommend rebuilds for all 15 packages.
>>
>> Maintainers of packages that link Matrix can implement an
>> .onLoad test for possible binary incompatibility by
>> comparing the value of
>>
>> if (utils::packageVersion("Matrix") >= "1.6.2")
>> Matrix::Matrix.Version()[["abi"]] else
>> numeric_version("0")
>>
>> at install time and at load time, warning the user if the
>> values differ. But please do look at the above and not
>> at packageVersion("Matrix") directly, as the ABI version
>> is incremented less often than the package version.
>>
>> Mikael {on behalf of citation("Matrix")$author}
>>
>> __
>> R-package-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>>
> [[alternative HTML version deleted]]
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Matrix 1.7-0 to be released in March with ABI-breaking SuiteSparse update
Hi Mikael
Revisiting this. Have the plans changed for 1.7-0 release?
Tim
On Mon, 12 Feb 2024, at 6:36 PM, Mikael Jagan wrote:
> Dear users and binary repository maintainers,
>
> We are preparing Matrix version 1.7-0 for CRAN submission on March 11, ahead
> of the spring release of R version 4.4.0. The only significant change from
> Matrix 1.6-5 is an update of the internal SuiteSparse libraries
> (5.10.1 -> 7.6.0). Unfortunately, the old and new SuiteSparse versions are
> binary incompatible, hence so too will be the old and new Matrix versions.
>
> A corollary is that users and binary repository maintainers switching between
> Matrix < 1.7-0 and Matrix >= 1.7-0 must rebuild _from sources_ packages that
> link Matrix:
>
> > tools::package_dependencies("Matrix", which = "LinkingTo", reverse =
> > TRUE)[[1L]]
> [1] "ahMLE" "bayesWatch" "cplm"
> [4] "GeneralizedWendland" "geostatsp" "irlba"
> [7] "lme4""mcmcsae" "OpenMx"
> [10] "PRIMME" "PUlasso" "robustlmm"
> [13] "spGARCH" "TMB" "bcSeq"
>
> For users, that means doing, e.g.,
>
> install.packages("lme4", type = "source")
>
> but an alternative for Windows and macOS users without the required tools is
>
> oo <- options(repos = "https://cran.r-project.org/;)
> install.packages("Matrix")
> install.packages("lme4")
> options(oo)
>
> where we trust CRAN to provide binaries compatible with the latest Matrix
> version (because we notify CRAN upon submission about required rebuilds).
> Once other repositories react with rebuilds, they can be used instead of
> CRAN.
>
> Our reverse dependency checks (and history, intuition, ...) show that most
> problems (caught segfaults in this case) can be traced to a binary
> incompatible
> lme4 and not to one of the other packages linking Matrix. Still, we recommend
> rebuilds for all 15 packages.
>
> Maintainers of packages that link Matrix can implement an .onLoad test for
> possible binary incompatibility by comparing the value of
>
> if (utils::packageVersion("Matrix") >= "1.6.2")
> Matrix::Matrix.Version()[["abi"]]
> else numeric_version("0")
>
> at install time and at load time, warning the user if the values differ.
> But please do look at the above and not at packageVersion("Matrix") directly,
> as the ABI version is incremented less often than the package version.
>
> Mikael {on behalf of citation("Matrix")$author}
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>
[[alternative HTML version deleted]]
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] Matrix 1.7-0 to be released in March with ABI-breaking SuiteSparse update
Dear users and binary repository maintainers,
We are preparing Matrix version 1.7-0 for CRAN submission on March 11, ahead
of the spring release of R version 4.4.0. The only significant change from
Matrix 1.6-5 is an update of the internal SuiteSparse libraries
(5.10.1 -> 7.6.0). Unfortunately, the old and new SuiteSparse versions are
binary incompatible, hence so too will be the old and new Matrix versions.
A corollary is that users and binary repository maintainers switching between
Matrix < 1.7-0 and Matrix >= 1.7-0 must rebuild _from sources_ packages that
link Matrix:
> tools::package_dependencies("Matrix", which = "LinkingTo", reverse =
TRUE)[[1L]]
[1] "ahMLE" "bayesWatch" "cplm"
[4] "GeneralizedWendland" "geostatsp" "irlba"
[7] "lme4""mcmcsae" "OpenMx"
[10] "PRIMME" "PUlasso" "robustlmm"
[13] "spGARCH" "TMB" "bcSeq"
For users, that means doing, e.g.,
install.packages("lme4", type = "source")
but an alternative for Windows and macOS users without the required tools is
oo <- options(repos = "https://cran.r-project.org/;)
install.packages("Matrix")
install.packages("lme4")
options(oo)
where we trust CRAN to provide binaries compatible with the latest Matrix
version (because we notify CRAN upon submission about required rebuilds).
Once other repositories react with rebuilds, they can be used instead of
CRAN.
Our reverse dependency checks (and history, intuition, ...) show that most
problems (caught segfaults in this case) can be traced to a binary incompatible
lme4 and not to one of the other packages linking Matrix. Still, we recommend
rebuilds for all 15 packages.
Maintainers of packages that link Matrix can implement an .onLoad test for
possible binary incompatibility by comparing the value of
if (utils::packageVersion("Matrix") >= "1.6.2")
Matrix::Matrix.Version()[["abi"]]
else numeric_version("0")
at install time and at load time, warning the user if the values differ.
But please do look at the above and not at packageVersion("Matrix") directly,
as the ABI version is incremented less often than the package version.
Mikael {on behalf of citation("Matrix")$author}
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
