You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
COMMITCOUNT allows to have the PKG_RELEASE calculated automatically based on the number of commits for the package folder. AUTORELEASE will count the number of commits since the last upstream bump. This is relevant for packages with PKG_VERSION or PKG_SOURCE_DATE set, but will not work for us since it assumes the use of certain identifiers in commit titles. COMMITCOUNT works fine for most of our packages, with the following exceptions: * fff-nodewatcher would yield a commit count of 55, while the current PKG_RELEASE is 61. Thus, we do not touch it for now. * Packages that have been renamed will start counting from 1 after the rename, since folder renames are not tracked by git. This will result in descreasing PKG_RELEASE after the change for these packages. However, since moving essentially creates a new package anyway, counting from 1 makes sense conceptually, and PKG_RELEASE is still replaced for these packages. * alfred-json and fff-macnock use upstream code and thus would normally require AUTORELEASE. As discussed above, this will not work for us, so just leave these two untouched. Note that all this is quite irrelevant for the way we use packages currently, as without opkg PKG_RELEASE does not matter to us anyway. So, let's just be happy about not having to bump PKG_RELEASE anymore, while keeping the basic functionality intact. The only package where the PKG_RELEASE is actually used for something is fff-nodewatcher, where the version will be displayed in the Monitoring. Signed-off-by: Adrian Schmutzler <email@example.com> [firstname.lastname@example.org: rebase, add new packages] Signed-off-by: Fabian Bläse <email@example.com> Reviewed-by: Robert Langhammer <firstname.lastname@example.org> Reviewed-by: Johannes Kimmel <email@example.com>
|1 year ago|
|files||1 year ago|
|Makefile||1 year ago|