105
edits
Changes
Jump to navigation
Jump to search
Line 125:
Line 125: − +
→Version number
* Some people want a much longer lead-up time to Sugar-1.0 so that the API can be refined/reworked/perfected
* Some people want a much longer lead-up time to Sugar-1.0 so that the API can be refined/reworked/perfected
Tomeu, Simon and Marco agreed that the 1.0 version number could be used here, and communicated in a slightly different sense: we are really still in the first iteration and 1.0 will be when that first iteration reaches maturity, without big changes in the API. After 1.0 we can start working on what will be one day 2.0 which should be the second iteration of Sugar, hopefully using what we have learned during these years.
Tomeu, Simon and Marco agreed that the 1.0 version number could be used here, and communicated in a slightly different sense: "we are really still in the first iteration and 1.0 will be when that first iteration reaches maturity, without big changes in the API. After 1.0 we can start working on what will be one day 2.0 which should be the second iteration of Sugar, hopefully using what we have learned during these years."
The migration of sugar-toolkit, sugar, datastore, etc, is likely to take more than 1 release cycle, but the above scheme can still apply. When each component is ported to GTK3, it would then pick up the 1.0 tag. For example, the first major release that includes any GTK3 may well include sugar-toolkit-1.0 (GTK3 ported) alongside sugar-datastore-0.96 (not yet ported).
The migration of sugar-toolkit, sugar, datastore, etc, is likely to take more than 1 release cycle, but the above scheme can still apply. When each component is ported to GTK3, it would then pick up the 1.0 tag. For example, the first major release that includes any GTK3 may well include sugar-toolkit-1.0 (GTK3 ported) alongside sugar-datastore-0.96 (not yet ported).