Thanks Mike for the additional details. Long due PR on buildpacks-docs at
[1]

Dieu, can you please comment on the suggestion above for more fine grained
buildpack versionning support ?

Thanks,

Guillaume.

[1] https://github.com/cloudfoundry/docs-buildpacks/pull/39

On Thu, Aug 6, 2015 at 8:02 PM, Mike Dalessio <mdalessio(a)pivotal.io>
wrote:

The /v2/buildpacks endpoint (used by the "cf buildpacks" command)
displays the last update date for a buildpack, e.g.

{
"metadata": {
"guid": "e000b78c-c898-419e-843c-2fd64175527e",
"url": "/v2/buildpacks/e000b78c-c898-419e-843c-2fd64175527e",
"created_at": "2014-04-08T22:05:34Z",
"updated_at": "2015-07-08T23:26:42Z"
},
"entity": {
"name": "java_buildpack",
"position": 3,
"enabled": true,
"locked": false,
"filename": "java-buildpack-v3.1.zip"
}
}

Would'nt it make sense to have the CC increment a version number for
each update so that it becomes easier to query than only relying on dates
comparison ?

While it's great to have buildpacks provide themselves detailed
versionning info for their code and their most important
dependencies/remote artifacts, I feel the cf platform should provide a bit
more support to help identify versions of buildpacks used by apps, such as:
- refine the app summary endpoint [g2]:
- for system buildpacks: include the buildpack guid (in addition to
the buildpack name) as to allow correlation to /v2/buildpacks endpoint
- for custom buildpacks (url): record and display the git hash
commit for a buildpack url
- refine the app listing endpoints [g4] or v3 [g5] to
- support querying app per system buildpack id
- support querying app by dates of "package_updated_at" or best a
version number as suggested above

I'm wondering whether the CAPI team working on API V3 is planning some
work in this area, and could comment the suggestions above.

I'll let Dieu respond to these suggestions, as she's the CAPI PM.