Changes

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.

However, if the migration of sugar-toolkit, sugar, datastore, etc, takes more than 1 release cycle (which it probably will), at which point do we switch to the 1.0 name? Personally, I think sugar-toolkit must be the first item to be ported, and being the most outward-facing component (on the code level), this would be a good opportunity to pick up the 1.0 tag. Version 1.2 could then include GTK3 ports of the other components, and so on.

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).

== API changes ==

== API changes ==