Difference between revisions of "Features/Dotted Activity Versions"

From Sugar Labs
Jump to: navigation, search
 
(20 intermediate revisions by 4 users not shown)
Line 1: Line 1:
<noinclude>{{TOCright}}
+
<noinclude>
[[Category:Feature Ready for Release Manager]]
+
[[Category:FeatureLanded|Dotted Activity Versions]]
[[Category:Feature|Dotted Activity Versions]]
+
</noinclude>
  
 
== Summary ==
 
== Summary ==
 
+
Extend the activity version numbering scheme to allow major and minor releases.
Let activity developers release bugfix versions and do not mess them with already released new versions(e.g. bugfix for several-versions-ago release w/o breaking/confusing-users existed versioning scheme).
 
  
 
== Owner ==
 
== Owner ==
''This should link to your home wiki page so we know who you are''
+
* Name: [[Users:Erikos| Simon Schampijer]]
* Name: [[User:AcountName| Your Name]]
 
  
''Include you email address that you can be reached should people want to contact you about helping with your feature, status is requested, or technical issues need to be resolved''
+
* Email: simon AT sugarlabs DOT org
* Email: <your email address so we can contact you, invite you to meetings, etc.>
 
  
 
== Current status ==
 
== Current status ==
* Targeted release: 0.88
+
* Targeted release: 0.92
* Last updated: Sun Dec  6 03:13:02 UTC 2009
+
* Last updated: Fri, 05 Nov 2010
* Percentage of completion: 0%
+
* Percentage of completion: 90%
  
 
== Detailed Description ==
 
== Detailed Description ==
 +
The new numbering scheme is more flexible and allows you to do major and minor releases. This is useful when you want to do for example a bug fix release. The new version number will consist of N integers separated by dots (e.g., 1, 1.2, 1.4.5, 2.5.7.4). You can still use an integer number only for your releases.
  
In case of backwards compatibility(how <0.88 and >=0.88 users will see new version), there could be several options:
+
There is as well the ability to use a suffix for a local indicator (e.g., Peru wants to release a slightly modified version for their deployment 1.3-peru). The local indicator is a string, appended to the version. The local indicator does not apply alpha ordering, which means that 1.3-peru is equal to 1.3-argentina.
  
* 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
+
Valid:
 +
1
 +
1.2
 +
1.2.3
 +
2.4.6.7
 +
2.3-peru
  
* 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)
+
Not valid:
 +
1.2peru        # must be separated with a '-'
 +
1.2.           # can't end with '.'
 +
1.02.5        # can't have a leading zero
  
* 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
+
Comparisons:
 +
12 == 12
 +
0.9.9 < 1
 +
1 == 1.0.0
 +
1.2 < 1.2.3
 +
1.2-arg == 1.2
 +
1.2-arg == 1.2-peru
  
 
== Benefit to Sugar ==
 
== Benefit to Sugar ==
 +
The new scheme gives activity developers more control on their releases. The separation between a major release and a minor (bugfix) release is more clearly visible. Since developers can still use just integer numbers the simplicity of the old scheme is kept.
  
Let activity developers release bugfix versions and do not mess them with already released new versions(e.g. bugfix for several-versions-ago release w/o breaking/confusing-users existed versioning scheme).
+
This scheme also enables developers who maintain older versions of Sugar, building activities with intermediate versions, in cases where it is not possible to use the latest changes because are not compatible.
  
 
== Scope ==
 
== Scope ==
 +
This feature does add a new class to the toolkit that is used to verify the correctness of the numbering string. The bundlebuilder and the activitybundle are adjusted accordingly ([http://bugs.sugarlabs.org/attachment/ticket/2425/0001-Adopt-to-new-numbering-scheme-2425.patch current toolkit patch]). In the shell the activity list and the bundleregistry has to change accordingly ([http://bugs.sugarlabs.org/attachment/ticket/2425/0001-Adopt-to-new-numbering-scheme-2425.patch current shell patch]).
  
This feature could affect versioning scheme of all existed activities.
+
Furthermore the activity updater has to adopt to the new scheme.
  
 
==UI Design==
 
==UI Design==
  
Nothing.
+
The new activity version is only visible in the activity list and the activity updater.  
  
 
== How To Test ==
 
== How To Test ==
{{:{{PAGENAME}}/Testing}}
+
 
 +
 
 
== User Experience ==
 
== User Experience ==
 
''If this feature is noticeable by its target audience, how will their experiences change as a result?  Describe what they will see or notice.''
 
''If this feature is noticeable by its target audience, how will their experiences change as a result?  Describe what they will see or notice.''
Line 52: Line 67:
 
== Contingency Plan ==
 
== Contingency Plan ==
  
None necessary, revert to previous release behaviour.
+
None necessary, revert to previous release behavior.
  
 
== Documentation ==
 
== Documentation ==
 
+
[[Development_Team/Almanac/Activity_Bundles#.info_file_format |The activity.info file documentation]] will be adjusted accordingly once this feature lands. The discussion about this feature has been taking place at this [http://www.mail-archive.com/sugar-devel@lists.sugarlabs.org/msg16943.html thread] on the sugar-devel mailing list.
* [http://www.mail-archive.com/sugar-devel@lists.sugarlabs.org/msg10591.html Activity Versioning - Dotted Scheme]
 
  
 
== Release Notes ==
 
== Release Notes ==
''The Sugar Release Notes inform end-users about what is new in the release. An Example is [[0.84/Notes]]. The release notes also help users know how to deal with platform changes such as ABIs/APIs, configuration or data file formats, or upgrade concerns.  If there are any such changes involved in this feature, indicate them here.  You can also link to upstream documentation if it satisfies this need.  This information forms the basis of the release notes edited by the release team and shipped with the release.''
 
  
 
== Comments and Discussion ==
 
== Comments and Discussion ==
 
* See [[{{TALKPAGENAME}}|discussion tab for this feature]] <!-- This adds a link to the "discussion" tab associated with your page.  This provides the ability to have ongoing comments or conversation without bogging down the main feature page. -->
 
* See [[{{TALKPAGENAME}}|discussion tab for this feature]] <!-- This adds a link to the "discussion" tab associated with your page.  This provides the ability to have ongoing comments or conversation without bogging down the main feature page. -->

Latest revision as of 13:59, 5 November 2013


Summary

Extend the activity version numbering scheme to allow major and minor releases.

Owner

  • Email: simon AT sugarlabs DOT org

Current status

  • Targeted release: 0.92
  • Last updated: Fri, 05 Nov 2010
  • Percentage of completion: 90%

Detailed Description

The new numbering scheme is more flexible and allows you to do major and minor releases. This is useful when you want to do for example a bug fix release. The new version number will consist of N integers separated by dots (e.g., 1, 1.2, 1.4.5, 2.5.7.4). You can still use an integer number only for your releases.

There is as well the ability to use a suffix for a local indicator (e.g., Peru wants to release a slightly modified version for their deployment 1.3-peru). The local indicator is a string, appended to the version. The local indicator does not apply alpha ordering, which means that 1.3-peru is equal to 1.3-argentina.

Valid:

1
1.2
1.2.3
2.4.6.7
2.3-peru

Not valid:

1.2peru        # must be separated with a '-'
1.2.           # can't end with '.'
1.02.5         # can't have a leading zero

Comparisons:

12 == 12
0.9.9 < 1
1 == 1.0.0
1.2 < 1.2.3
1.2-arg == 1.2
1.2-arg == 1.2-peru

Benefit to Sugar

The new scheme gives activity developers more control on their releases. The separation between a major release and a minor (bugfix) release is more clearly visible. Since developers can still use just integer numbers the simplicity of the old scheme is kept.

This scheme also enables developers who maintain older versions of Sugar, building activities with intermediate versions, in cases where it is not possible to use the latest changes because are not compatible.

Scope

This feature does add a new class to the toolkit that is used to verify the correctness of the numbering string. The bundlebuilder and the activitybundle are adjusted accordingly (current toolkit patch). In the shell the activity list and the bundleregistry has to change accordingly (current shell patch).

Furthermore the activity updater has to adopt to the new scheme.

UI Design

The new activity version is only visible in the activity list and the activity updater.

How To Test

User Experience

If this feature is noticeable by its target audience, how will their experiences change as a result? Describe what they will see or notice.

Dependencies

Regular glucose dependencies.

Contingency Plan

None necessary, revert to previous release behavior.

Documentation

The activity.info file documentation will be adjusted accordingly once this feature lands. The discussion about this feature has been taking place at this thread on the sugar-devel mailing list.

Release Notes

Comments and Discussion