[R-pkg-devel] Submitting breaking changes to CRAN

[Ege Rubak]

Dear Duncan,

Thanks for spending time on this. You are right that there were some
incompatibility issues for people with old spatstat installed along
side spatstat.xxxx, and we might have been fix some of that, but it was
not completely clear to us. However, the problem is now solved as
spatstat 2.0-1 is on CRAN thanks to Uwe and the rest of the team. The
waiting time was explained by the fact that CRAN tackles packages with
many broken reverse dependencies separately and they had recently
worked on another case.

Best,
Ege


On Fri, 2021-03-12 at 09:46 -0500, Duncan Murdoch wrote:
> One part of your first message that I don't understand is the
> reluctance 
> of downstream package writers to update to the spatstat.xxxx
> versions.
> 
> You said "Many have reported back that they have a new version ready 
> that will work with spatstat (>=2.0) and are waiting to submit until
> it 
> is on CRAN."
> 
> Why wouldn't those new versions work already?  I'm guessing there is 
> some incompatibility between the new spatstat.xxxx packages and the
> old 
> spatstat 1.65 from before the split.  Can you describe what it is? 
> Maybe there's a way to make the new packages compatible with the old 
> one, so there would be no excuse for the downstream packages not to 
> update right away.
> 
> Duncan Murdoch
> 
> 
> On 11/03/2021 7:39 p.m., Ege Rubak wrote:
> > Dear Duncan,
> > 
> > Thanks for taking the time to read my message and for the
> > constructive
> > idea. You are right that it is a bit late for us to do this now.
> > Given
> > that spatstat (<=1.65) exports >2,500 objects which are now spread
> > across sub-packages we would obviously have to make a script to
> > help us
> > reexport the functions and make documentation containing links to
> > the
> > real man page. This might be doable, but one big downside is that
> > we
> > then don't use this occasion to move package dependencies from
> > spatstat
> > to the relevant spatstat.xxxx. If the packages don't fail I'm
> > afraid
> > that a lot of maintainers wont change anything, and their package
> > will
> > depend on the entire ensemble of spatstat packages rather than just
> > the
> > relevant sub-package(s). For our usual end users this would also
> > mean
> > that when they open the help file of given function after attaching
> > spatstat it will just contain a huge list of links to the real help
> > file they are looking for which is a nuisance.
> > 
> > Unless we get other really good suggestions we will wait a bit more
> > on
> > a reply from CRAN (we sent a gentle reminder a week ago) and
> > hopefully
> > learn what we should do differently to get the last bit in place.
> > 
> > Best regards,
> > Ege
> > 
> > 
> > On Thu, 2021-03-11 at 14:56 -0500, Duncan Murdoch wrote:
> > > It may be too late to do this now, but you could use the approach
> > > that
> > > devtools used when it was broken up:  The main package imports
> > > functions
> > > from the new spatstat.xxxx packages and exports them.  This way
> > > it
> > > could
> > > be done with no breaking changes.  Reverse dependencies could
> > > change
> > > to
> > > depend on spatstat.xxxx at their leisure.
> > > 
> > > Duncan Murdoch
> > > 
> > > On 11/03/2021 10:18 a.m., Ege Rubak wrote:
> > > > Dear all,
> > > > 
> > > > I'm seeking advice on how to submit a new package version with
> > > > breaking
> > > > changes to CRAN. I will try to make this short:
> > > > 
> > > > 1. spatstat (<= 1.65) had grow to be very large with extensive
> > > > examples, tests, and documentation.
> > > > 2. CRAN asked us to reduce package size and check time.
> > > > 3. We reorganized the package into a new umbrella package
> > > > spatstat
> > > > 2.0
> > > > which Depends/Imports several subpackages named spatstat.xxxx.
> > > > 4. All subpackages are now on CRAN.
> > > > 5. We submitted spatstat 2.0-1 which breaks 79 reverse
> > > > dependencies
> > > > because they e.g. call functions that have been moved from
> > > > spatstat
> > > > to
> > > > spatstat.xxxx.
> > > > 6. All maintainers have been warned over a period of months and
> > > > offered
> > > > detailed help to adjust their package. Many have reported back
> > > > that
> > > > they have a new version ready that will work with spatstat
> > > > (>=2.0)
> > > > and
> > > > are waiting to submit until it is on CRAN.
> > > > 7. We received notification on 23 Feburary that "package
> > > > spatstat_2.0-
> > > > 1.tar.gz has been auto-processed. The auto-check found problems
> > > > when
> > > > checking the first order strong reverse dependencies.
> > > > Please reply-all and explain: Is this expected or do you need
> > > > to
> > > > fix
> > > > anything in your package? If expected, have all maintainers of
> > > > affected
> > > > packages been informed well in advance? Are there false
> > > > positives
> > > > in
> > > > our results?"
> > > > 8. We replied to all on the same day, 23 Feb, that this was
> > > > expected
> > > > and maintainers had been informed. Since then we have no news.
> > > > 
> > > > Any advice on how to cross the finish line and get spatstat
> > > > 2.0-1
> > > > on
> > > > CRAN without putting too big a burden on the CRAN volunteers?
> > > > 
> > > > I can only come up with a long shot:
> > > > 
> > > > Ask package maintainers to submit their spatstat 2.0 compatible
> > > > package
> > > > to CRAN with an additional line in DESCRIPTION:
> > > > 
> > > > Additional_repositories: https://spatstat.r-universe.dev
> > > > 
> > > > Since spatstat 2.0-1 is available from this repository they may
> > > > pass
> > > > the incoming checks on CRAN, but my hopes are not too high.
> > > > 
> > > > If this was successful the reverse dependencies would be
> > > > compatible
> > > > with spatstat 2.0 and on CRAN and so spatstat 2.0 would break
> > > > nothing
> > > > and we could resubmit.
> > > > 
> > > > Best regards,
> > > > Ege
> > > > 
> > > >