[Sugar-devel] [ANNOUNCE] Schedule after Sugar 0.90.0 is released --- or "After the game is before the game"
simon at schampijer.de
Wed Oct 6 10:54:04 EDT 2010
Dear Sugar community,
after successfully releasing 0.90 there should be a
to celebrate what has been achieved and then we can start thinking what
to do next. Some items are rather near term goals but there is as well
the long road that leads to a new release --- 0.92 (1.0).
=== Branching ===
After the final release of a module, a branch should be created to host
further stable development. If you do not have an 'unstable' commit yet
you can leave your branch as is, as this ease the work for translators
by not having to translate for two branches. The details about branching
are described at .
=== Bug fix release ===
To make sure we have the latest packages in F14 before the Final Change
deadline happens the 18th of October , I added another bug fix
release . As Fedora is the bleeding edge at the moment we just
backpack on this date.
* 0.90.1 will be the 15th of October
* 0.90.2 will be the 27th of October
=== Testing 0.90 ===
So far we have not seen much testing of 0.90 yet, that is why the bug
fix releases noted above are so important to us. We need as well your
help to actually discover the bugs! There are basically three ways how
you can test as of today (besides using sugar-jhbuild):
* Install Fedora 14 on a machine and install the Sugar desktop
* Test using Sugar on a stick: Get one of the nightly snapshots  and
put it on a usb key. You can find instructions about it at . It is
good to subscribe to the Soas mailing list (low traffic)  for
announcement and discussions in that case.
* If you have an XO (XO-1 or XO-1.5) you can use an image from .
If you are aware of any other distribution where Sugar 0.90 can be
tested easily please comment.
=== 0.92 ===
Based on the GNOME schedule I made a first draft of the 0.92 roadmap. I
reintroduced the "Feature Acceptance" milestone. The idea is that the
discussion about a feature does not start one day before the feature
freeze. As stated in the Feature policy  the acceptance is a sanity
check, presumed in most cases to be a formality, to ensure that new
features compliment Sugar guidelines and is manageable, prior to
publicizing as officially targeted for the next release. The actual code
must be ready by the Feature Freeze and is reviewed by the module
On behalf of the Sugar community,
Your Release Team
More information about the Sugar-devel