You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In #6829@TysonStanley and I discussed pushing the as-submitted CRAN release to GitHub to allow other Committers to merge it once the update is accepted by CRAN.
That would help minimize the time between a CRAN acceptance and an update here, without requiring the CRAN maintainer to operate with 24/7 availability.
However, we do have this note in the CRAN release today:
# DO NOT even use a PR. Because PRs build binaries and we don't want any binary versions of even release numbers available from anywhere other than CRAN.
IINM, we should be able to update the CI configs so that certain branches/rules don't trigger the generation of binaries, etc. & thus avoid the concern mentioned here.
E.g., the rule could be "push to a branch specifically named cran-release", and our configs actively exclude that specific name.
The text was updated successfully, but these errors were encountered:
In #6829 @TysonStanley and I discussed pushing the as-submitted CRAN release to GitHub to allow other Committers to merge it once the update is accepted by CRAN.
That would help minimize the time between a CRAN acceptance and an update here, without requiring the CRAN maintainer to operate with 24/7 availability.
However, we do have this note in the CRAN release today:
data.table/.dev/CRAN_Release.cmd
Line 601 in 299d44d
IINM, we should be able to update the CI configs so that certain branches/rules don't trigger the generation of binaries, etc. & thus avoid the concern mentioned here.
E.g., the rule could be "push to a branch specifically named
cran-release
", and our configs actively exclude that specific name.The text was updated successfully, but these errors were encountered: