Features/Dotted Activity Versions: Difference between revisions

Line 21:

== Detailed Description ==

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.~~ ~~<0.88 user will see ''activity_version'', and >=0.88 version from new field~~ ~~could lead to various misunderstanding e.g. why''activity_version'' has one value and ''new_field'' has another one

* use two separate ''activity.info'' fields for version, existing ''activity_version'' and new one with new full version. < 0.88 user will see ''activity_version'', and >= 0.88 version from new field 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~~ ~~<0.88 user will see only ''activity_version'' and >=0.88 ''activity_version''.''new_field'' version~~ ~~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 existing ''activity_version'' field as a major part of dotted version and new field for minor part, < 0.88 user will see only ''activity_version'' and >= 0.88 will see ''activity_version''.''new_field'' version, in that case we don't break existing 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~~ ~~<0.88 user will see only ''activity_version'' and >=0.88 ''new_field''.''activity_version'' version~~ ~~also doesn't break versioning line but could confuse >=0.88 users who upgrade ~~theirs~~ sugar to 0.88 and will see Browse-2.105

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

== Benefit to Sugar ==

@@ Line 21: / Line 21: @@
 == Detailed Description ==
-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<br>could lead to various misunderstanding e.g. why''activity_version'' has one value and ''new_field'' has another one
+* use two separate ''activity.info'' fields for version, existing ''activity_version'' and new one with new full version. < 0.88 user will see ''activity_version'', and >= 0.88 version from new field 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<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 existing ''activity_version'' field as a major part of dotted version and new field for minor part, < 0.88 user will see only ''activity_version'' and >= 0.88 will see ''activity_version''.''new_field'' version, in that case we don't break existing 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<br>also doesn't break versioning line but could confuse >=0.88 users who upgrade theirs sugar to 0.88 and will see Browse-2.105
+* reuse existing ''activity_version'' field as a minor part of dotted version and new field for major part < 0.88 user will see only ''activity_version'' and >= 0.88 ''new_field''.''activity_version'' version also doesn't break versioning line but could confuse >=0.88 users who upgrade their sugar to 0.88 and will see Browse-2.105
 == Benefit to Sugar ==