Changes

Line 23: Line 23:  
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 ==