Changes

* ''sweet_id'', sweet identifier from the project recipe

* ''sweet_id'', sweet identifier from the project recipe

The same unique identifier might be associated with several sweet implementations from the same doer. Implementation is just a copy of the sweet in ready-to-use state, e.g., several versions of the sweet, several binary implementations of the same sweet version built against several environments. Only one implementation will be chosen in running environment basing on Operating System, GNU/Linux distribution, or user preferences (like running only stable versions).

The same unique identifier might be associated with several sweet implementations from the same doer. Implementation is just a copy of the sweet in ready-to-use state, e.g., several versions of the sweet, several binary implementations of the same sweet version built against several environments. Only one implementation will be chosen in running environment basing on operating system, hardware architecture, GNU/Linux distribution or user preferences (like running only stable versions).

The reason to have second type of sweet identifiers is collecting sweet implementations from several doers. For example, doer might tweak existed project and share it, other people will be aware of existence of another sweet implementations. The process of choosing the proper implementation to run, will be extended by additional options like choosing implementations only from particular doer.

The reason to have second type of sweet identifiers is collecting sweet implementations from several doers. For example, doer might tweak existed project and share it, other people will be aware of existence of another sweet implementations. The process of choosing the proper implementation to run will be extended by additional options like choosing implementations only from particular doer.

==== Development implementations ====

==== Development implementations ====