Changes

In case of backwards compatibility(how <0.88 and >=0.88 users will see new version), there could be several options:

In case of backwards compatibility(how <0.88 and >=0.88 users will see new version), there could be several options:

* use two separate ''activity.info'' fields for version, existed ''activity_version'' and new one with new full version.<br><0.88 user will see ''activity_version'', and >=0.88 version from new field

* use two separate ''activity.info'' fields for version, existed ''activity_version'' and new one with new full version.<br><0.88 user will see ''activity_version'', and >=0.88 version from new field<br>could lead to various misunderstanding e.g. why''activity_version'' has one value and ''new_field'' has another one

* reuse existed ''activity_version'' field as a major part of dotted version and new field for minor part<br><0.88 user will see only ''activity_version'' and >=0.88 ''activity_version''.''new_field'' version

* reuse existed ''activity_version'' field as a major part of dotted version and new field for minor part<br><0.88 user will see only ''activity_version'' and >=0.88 ''activity_version''.''new_field'' version<br>in that case we don't break existed versioning line e.g. Browse-104 will be Browse-104(even after adding new version w/ incremented ''new_field'' value) for all sugars(but >=0.88 users will see incremented part)

* reuse existed ''activity_version'' field as a minor part of dotted version and new field for major part<br><0.88 user will see only ''activity_version'' and >=0.88 ''new_field''.''activity_version'' version

* reuse existed ''activity_version'' field as a minor part of dotted version and new field for major part<br><0.88 user will see only ''activity_version'' and >=0.88 ''new_field''.''activity_version'' version<br>also doesn't break versioning line but could confuse >=0.88 users that upgrade theirs sugar to 0.88 and will see Browse-2.104

== Benefit to Sugar ==

== Benefit to Sugar ==