Github user ahgittin commented on the pull request:
https://github.com/apache/incubator-brooklyn/pull/92#issuecomment-61803962
Good discussion just now with @aledsage and @neykov . Conclusions include
some changes to the above proposal:
* When no version is specified, call it `0.0.0_SNAPSHOT`.
* Not necessary now to apply monotonic increasing qualifier on conflict,
and potentially surprising. We should just fail if the version exists. If it
is easy in selected cases (viz. `0.0.0_SNAPSHOT` or perhaps all items
`*_SNAPSHOT*`), monotonic increasing qualifier could be appended there
automatically on conflict.
* We do not need to support setting a default version on the catalog for
now. The highest version (preferring non-snapshot) is used when a caller does
not request a version.
* In YAML we will support the fields above (viz. including `name` in
addition to `symbolicName`, `version`, `id`, and `displayName`), but in our
examples we will follow a consistent approach, viz. `id`. The others (in
particular `name`) might be deprecated in the future to minimize the number of
ways of doing this. (Or we may experiment and discover that `name` is actually
really nice, or all these ays are nice, and then keep this status quo or
deprecate some of the other items, TBD!)
Other tasks TODO:
* Test whether we can do anything for OSGi multiple instances of the same
version. I thought this was the behaviour but turns out if you have two
bundles with the same `name:version`, we use any of them, irrespective of the
defining URL. If we can differentiate between them based on URL we should.
(Alex to check.)
* Write documentation for adding to catalog, with examples, and setting
versions and how those work. Include `force`, and the importance of OSGi
versioning and behaviour there (including the fact that restart might pick up
different bundles, in good ways and bad.)
* After this task, we'll need a way to update entities from one catalog
item id version to another. (I could see this as supplying a map of catalog
item id regex->target which should be upgraded, discovering the matching
entities, selecting all/any of them, and then deserializing and reserializing
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at [email protected] or file a JIRA ticket
with INFRA.
---
