r-spatial/sftime

Release sftime 0.2-0

Closed this issue ยท 25 comments

edzer commented

First release:

Prepare for release:

  • urlchecker::url_check()
  • devtools::check(remote = TRUE, manual = TRUE)
  • devtools::check_win_devel()
  • rhub::check_for_cran()
  • Draft blog post

Submit to CRAN:

  • devtools::submit_cran()
  • Approve email
  • Resubmit to CRAN

Wait for CRAN...

  • Accepted ๐ŸŽ‰
  • usethis::use_news_md()
  • usethis::use_github_release()
  • usethis::use_dev_version()
  • Finish blog post
  • Tweet
  • Add link to blog post in pkgdown news menu
edzer commented

@henningte this issue was created with usethis::use_release_issue(version = "0.2-0"). Feel free to continue checking the buttons; several of them need to be done by the package maintainer.

Hi @edzer,

I assume you have already used devtools::check_win_devel() since I have received an email from win-builder.r-project.org. There is one note which I assume has no influence on the success of the CRAN submission (?):

New submission

Possibly misspelled words in DESCRIPTION:
  sortable (4:192)
  spatiotemporal (4:118, 4:221)

Is "Update (aspirational) install instructions in README" done? I could not find any related changes in the repository.

I've run rhub::check_for_cran() which produces the same note quoted above on all three default machines.

edzer commented

I changed sortable into ordinal. I think spatiotemporal will not lead to problems.

edzer commented

I don't think the README instructions are required.

I don't think the README instructions are required.

Wouldn't a README be the place to acknowledge the funding source - or doesn't this matter for the CRAN submission?

Do you write your READMEs as markdown files or do you compile these from an Rmarkdown file? I would like to set up at least a bare minimum, if the README is not required for the CRAN submission then I'll do this after the CRAN submission.

And a final point: Do you have any wishes for the blog post? I thought of the blog post being nearly identical to the vignette, perhaps with a more elaborate introduction (e.g. to potential use cases) and an outlook to the integration with gstat and spcopula.

And thanks for the list!

edzer commented

README is not part of the source package. Yes, README should acknowledge the funding, you can use the sf template for this. Package stars has an example of a README.Rmd, but I (believe) I process that locally into the .md.

For the blog post: yes, the vignette contains good illustrations. The blog post should be shorter, doesn't have to include all examples, and should have more of a motivating introduction (why we need this package: it replaces STIDF in spacetime, a class that doesn't fit into stars).

A brief update:

  1. I've added a README.Rmd and produced content which I would consider to represent the minimum.
  2. I also added a code of conduct. If I should make changes here, tell me. Currently, I put my email address as contact information into the code of conduct, but I have no experience to handle such cases.
  3. I'm currently preparing the blog post. As test data, I plan to use the storm trajectory data you also used in the Tidy storm trajectories blog post.
  4. While doing this, I faced a problem when dropping the geometry column. That's why I opened an issue in the sf repo

I have the following questions:

  1. Where should I put drafts for the blog post so that you can review them?
  2. What authorship order do you prefer for the blog post? I don't care, but if you do, I'll adopt what you propose.

And another question:

Should the blog post already foreshadow the gstat and spcopula integration, since I think this is what people certainly are interested in?

edzer commented
  1. https://github.com/r-spatial/r-spatial.org/ , source files are in the _rmd subdirectory.
  2. you, Ben, me?

Should the blog post already foreshadow the gstat and spcopula integration, since I think this is what people certainly are interested in?

Yes.

Brief update:

  • I will work on the blog post at https://github.com/henningte/r-spatial.org.
  • I have implemented the st_drop_geometry.sftime() method (from this sf issue). The problem is now that sftime depends on a non-CRAN sf version (this is also why the checks in the sftime repository fail). I guess this would be problematic for the CRAN submission?
edzer commented

I guess this would be problematic for the CRAN submission?

Yes, but I will try to get this on CRAN in the next few days.

edzer commented

sf 1.0-7 is on CRAN now.

@edzer , @BenGraeler ,

I have now drafted a first blogpost. It is not yet perfect and I don't know if it is engaging enough.

I am interested in a first opinion from you:

  • What should I modify, what should I add or remove?
  • Are the examples fine?
  • Do we need more pictures?

And I have two questions for the CRAN submission:

  • Should I merge the dev branch in the main branch before submitting to CRAN?
  • And finally, most important: Can I submit the package to CRAN now (of course after incrementing the version number)?
edzer commented

Should I merge the dev branch in the main branch before submitting to CRAN?

Yes.

And finally, most important: Can I submit the package to CRAN now

Yes.

after incrementing the version number

I only increase version numbers after the current version has been accepted on CRAN. CRAN is where the release happens.

I only increase version numbers after the current version has been accepted on CRAN. CRAN is where the release happens.

ok, so the current version is the version being submitted to CRAN and the version increment applies to all changes thereafter, right?

Sorry if this question seems stupid. I interpreted the checklist as having a temporal order which then is only partly the case ...

edzer commented

Yes, weird - CRAN checks always check whether the version number is higher than the one of the current CRAN version.

We've got the following comments. I will work on it:

Please always write package names, software names and API (application programming interface) names in single quotes in title and description. e.g: --> 'stars'

Please add \value to .Rd files regarding exported methods and explain the functions results in the documentation. Please write about the structure of the output (class) and also what the output means. (If a function does not return a value, please document that too, e.g. \value{No return value, called for side effects} or similar)
Missing Rd-tags:
plot.sftime.Rd: \value
st_as_sftime.Rd: \value
transform.sftime.Rd: \value

Please fix and resubmit.

Sounds good now!

Thanks,
on its way to CRAN.

edzer commented

Congratulations!

Great, Thanks a lot Henning!

edzer commented

Suggestions for the blog post:

  • provide a more useful link to the sf package, for instance https://r-spatial.github.io/sf/ and not the 2016 blog post
  • in the plot of the storms data, what does color indicate?
  • mention that the beginning of time periods are shown in the plot as panel titles, not the time intervals as such
  • maybe give a list (table?) of the classes from and to which now sftime objects can be converted, and with which command this is done
  • improve the description of the distinction with stars objects (I can do that!)
  • create a PR against r-spatial.org
  • list which tidyverse verbs are available? Or which methods are available in general, e.g. with
> library(sftime)
Loading required package: sf
Linking to GEOS 3.10.1, GDAL 3.4.0, PROJ 8.2.0; sf_use_s2() is TRUE
> library(tidyverse)
โ”€โ”€ Attaching packages โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€ tidyverse 1.3.1 โ”€โ”€
โœ” ggplot2 3.3.5     โœ” purrr   0.3.4
โœ” tibble  3.1.6     โœ” dplyr   1.0.7
โœ” tidyr   1.2.0     โœ” stringr 1.4.0
โœ” readr   2.1.1     โœ” forcats 0.5.1
โ”€โ”€ Conflicts โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€ tidyverse_conflicts() โ”€โ”€
โœ– dplyr::filter() masks stats::filter()
โœ– dplyr::lag()    masks stats::lag()
> methods(class = "sftime")
 [1] [                 [[<-              $<-               anti_join        
 [5] arrange           cbind             distinct          filter           
 [9] full_join         gather            group_by          inner_join       
[13] left_join         mutate            nest              pivot_longer     
[17] plot              print             rbind             rename           
[21] right_join        rowwise           sample_frac       sample_n         
[25] select            semi_join         separate_rows     separate         
[29] slice             spread            st_as_sftime      st_cast          
[33] st_crop           st_difference     st_drop_geometry  st_filter        
[37] st_intersection   st_join           st_sym_difference st_time          
[41] st_time<-         st_union          summarise         summarize        
[45] transform         transmute         ungroup           unite            
[49] unnest           

@edzer , @BenGraeler

I have worked through the list.

One point which was not clear to me: The link to the sf package was to the GitHub repo (https://github.com/r-spatial/sf), not the blog. Anyways, I changed the link as you suggested (just notifying you in case you meant something different).

Regarding the second example: I now use data from the geospatial package which is a subset of the earthquake data I have shown you.

In case there's something I should change, please let me know!

@edzer, how did you built the pkgdown site? Can I change this to a github action workflow which builds the site automatically when pushing to the main branch?

@edzer usethis::use_pkgdown_github_pages() worked out of the box. The site is now updated.

If you want to have anything changed on the site, please let me know.

The last open point in the checklist is to link the blog post on the sftime site. Do you have any preferences for how to do this?
If not, I would add a point "Articles" to the top navbar with an entry linking to the blog post.

edzer commented

Sounds like a good idea!