CRAN v1.6.9.21

@guillaume.thirel and @david.dorchies do you agree to submit airGR v1.6.9.21 to the CRAN?

The CI didn't success because you have remove some variables in the example (TimeFormat, YearFirstMonth, ConvertFun). They exists in the stable version and not anymore so the regression test say that there is a difference.

To skip the test on these variables, add them to the .regressionignore file located at the root of the repository.

In fact, only YearFirstMonth was missing in the .regressionignore of the newSeriesAggreg branch.

@david.dorchies don't you find it is confusing for the user if getAggregConvertFun() is private? It means that he can't see what is the default values of the ConvertFun argument does: getAggregConvertFun(names(x)[-1])

You are right. Since it is a default argument of ConvertFun argument of SeriesAggreg it should be documented. But I don't think that this function is useful for the user.

The only information really useful for the user is the data.frame .AggregConvertFunTable which is already public.

So I suggest to use an argument ConvertFunTable = .AggregConvertFunTable instead of ConvertFun = .AggregConvertFun(names(TabSeries)[-1]) in SeriesAggreg and to call the private function getAggregConvertFun(ConvertFunTable) in SeriesAggreg.

... And .AggregConvertFunTable should be better documented either in the SeriesAggreg page or in a dedicated page.

In this case, why not just keep only the argument ConvertFun = NULL by default and explain in the help page that in this case it uses the table .AggregConvertFunTable. A ConvertFunTable argument will not be very easy to check. Don't you think so?

A ConvertFunTable argument will not be very easy to check. Don't you think so?

I don't think so. It involves only 4 conditions:

if(!is.data.frame(ConvertFunTable) stop...
if(names(ConvertFunTable) != c("ConvertFun", "Outputs")) stop...
if(!all(ConvertFunTable$ConvertFun %in% c("mean", "sum"))) stop...
if(!is.character(ConvertFunTable$Outputs)) stop

I still think that exposing ConvertFunTable instead of ConvertFunis a better idea because:

• it's more complicated for the user to write a ConvertFun function than modifying .AggregConvertFunTable or create is own two column-data.frame
• now that you've added messages in getAggregConvertFun for unknown object, it should not be overwritten by the user in SeriesAggreg

@david.dorchies, to be consistent with v1.6.9.1 (see commit 1a95e4af).

@francois.bourgin, do you approve?

Yes, it looks better, thank you

changed milestone to %v1.6.10

added 1 commit

• bfeda6d4 - docs(NEWS): fix issue number

Compare with previous version

added 1 commit

• e8d4a9cf - docs(NEWS): fix minor typo

Compare with previous version

I agree.

I haven't done yet another proofreading of code and documentation but I think that this version is ready for release

approved this merge request

merged

mentioned in commit 3f30fdb5