Package's annual maintenance

jdblischak · February 16, 2024, 7:44pm

If you're still actively developing the package, then yes you should bump the year in the license file if you have them. For example, if you are using the typical setup for the MIT license, you should bump the year in LICENSE and LICENSE.md.

E.g., should I update the year in the CITATION file?

Do you have a custom citation file for your package? In that case you are probably citing a publication, and you should leave the year as the date of the publication.

If you don't have a citation file, then you don't need to do anything. The function citation() automatically pulls the date from the field Date/Publication in DESCRIPTION (this field is automatically added when you install the package).

github.com

wch/r-source/blob/d0acd2ad6cd5a970c8e7c18234ac0e6b75338315/src/library/utils/R/citation.R#L1332


      
          
              ## Base packages without a CITATION file use the base citation.
              if((!is.null(meta$Priority)) && (meta$Priority == "base")) {
              	cit <- citation("base", auto = FALSE)
              	attr(cit, "mheader")[1L] <-
          	    paste0("The ", sQuote(package), " package is part of R.  ",
          		   attr(cit, "mheader")[1L])
                  return(.citation(cit, package))
              }
          
              year <- sub("-.*", "", meta[["Date/Publication"]])
              if(!length(year) && !is.null(date <- meta[["Date"]])) {
                  date <- trimws(as.vector(date))[1L]
                  date <- strptime(date, "%Y-%m-%d", tz = "GMT")
                  if(!is.na(date)) year <- format(date, "%Y")
              }
              ## If neither Date/Publication nor Date work, try Packaged (build
              ## time stamp): if this fails too, use NA (PR #16550).
              if(!length(year)) {
                  date <- as.POSIXlt(sub(";.*", "", trimws(meta$Packaged)[1L]))
                  if(!is.na(date)) year <- format(date, "%Y")

Now what I don't know is whether it is better to use a date range (eg 2023-2024) or just the current year (2024) when asserting your copyright. As with most legal advice around software I find on the internet, when I searched for the answer, I found tons of conflicting advice. If anyone has an authoritative source, I'd love to read it.