Clay, Clay Baenziger wrote: > Hi Ethan, > With regards to bug 7383. I see issues surrounding this bug as: > * Being able to ensure an AI client gets a manifest with keywords > which it supports (i.e. server running build Y, client running > build X, x<y) > * Being able to identify what build (of our bits) an AI client is > running
Can you elaborate on how you see the second bullet is related? That seems to be more an issue of the installer bits being compatible with bits that are laid down. I sent out a separate proposal for that earlier this week. Feel free to comment on that. > > To achieve these two ends: > * The schema could define what changeset (of slim_source) the > feature being defined was added. (Perhaps just a changeset=### > attribute that can be added to features in the schema.) Then, > publish_manifest will store what the minimum changeset necessary > for that schema in the criteria database as a criteria. I think you're confusing the changeset ID with the revision number. What you're describing above requires a sequential ordering, but changeset IDs are not sequentially ordered, they are just 40 digit hex unique identifiers. The revision number is ordered, but they would be unreliable for this usage because you can't rely on them to be the same over time. i.e. revision number 545 isn't always going to describe changeset X. See this URL for descriptions of these Mercurial terms http://www.selenic.com/mercurial/wiki/index.cgi/FAQ#head-64d21ec75f556ed21f840436727a82655fdfb5ac > * The client can send which changeset of slim_source it was built > off of in the AI server<->client criteria exchange. Exactly my point. Once you record the revision number off into the built image, you can't reliably compare it back to the revision number in the manifest because the former or latter's revision number could have been gotten after a shift. > * Then all that is necessary to ensure the client gets an > appropriate manifest is to have the AI webserver treat the > changeset criteria as just any other criteria -- no work > necessary. I think you're on the right track with this, but instead of using the repository revision numbers, why not just cook up our own ordered numbers every time we change/add features to the manifest? What's wrong with 1, 2, 3, ... thanks, -ethan > > I see this as requiring fairly little implementation (~5 days with > testing). Let me know what's might be missed by such an approach or how > else versioning could be done though. > Thank you, > Clay
