Github user neykov commented on the pull request:
https://github.com/apache/incubator-brooklyn/pull/92#issuecomment-50636154
These are all great suggestions, it seems that the consensus in the area
(Chef, Puppet, et al, even OSGi) allows for requesting an item without
explicitly specifying a version. This allows the users not to care about
versioning until they really need to.
Specifically for creating items, isn't it cleaner (from a usage
perspective) that we don't support versionless items? They make the behaviour
too overloaded. Of course existing items should be supported but the behaviour
deprecated and removed in a subsequent version.
I think items "picked up from java classes" should be versioned as well. If
coming from an OSGi bundle then it would be great if we could retrieve the
version from the bundle but I don't this is possible.
Having immutable catalog items seems like a desired goal especially when we
have them serialized and mirrored by other nodes. It would be clear how an
existing instance was created even if the catalog items it relies on were
updated to a newer version and aliases updated.
It seems that your suggestion still could fit in an immutable catalog which
doesn't allow versionless items:
* for existing items without version create them with version 0.0.0
* require explicit versioning for new items as per semver
* the alias (items with explicitly set version: default) could have
version 999.0.0
* when an item is referenced without a version use the latest stable
version for that id
* there could be an exception to update the catalog items for legacy and
default versions or better yet, automatically increment the version (i.e. 0.0.1
for the next update of a legacy item without version, 999.0.1 for the next
update of a default item)
* no need to support force
* the only immutable operation would be delete, which as a side effect
would allow a subsequent addition with the same version, or maybe delete should
just be marking it as non-accessible?
---
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.
---
