[sugar] Release schedule and process

[Marco Pesenti Gritti]

On Tue, May 13, 2008 at 6:41 PM, Walter Bender <walter.bender at gmail.com> wrote:
> Ah. I was missing a subtly: do we agree that activities can be
>  released on their own timeframe, but that some activities are released
>  with the Sugar releases? For example, Write could be updated whenever
>  the Abiword team feels it is appropriate, perhaps in sync with other
>  Abiword releases, but a Sugar release would always include a working
>  Write? Is this the Gnome model?

In GNOME applications tend to sync up with GNOME at least until the
stable release. Then usually distributions start to ship them and each
projects does his own releases in response to critical bugs reported
etc. It also happens that some applications skip a cycle and GNOME
ship with the latest stable release.

I think we should just be flexible in this respect:

* In the normal case maintainers of activities included in the Sugar
release process should be willing to follow the schedule, i.e. provide
development and stable releases more or less in sync with the Sugar
process.
* If there is a need to skip a development cycle (for example because
the developers are working on large features or refactoring of the
code) it's fine to do so.
* Activities are encouraged to release stable updates outside the
Sugar dev cycle when there is need to do so.

>  In some cases, there is more than one choice for a core activity:
>  there are at least three credible Draw programs at the moment. Which
>  one is folded into the Sugar release is an interesting
>  question--somewhat different from the question of what are core
>  activities.

The Sugar community would bless one of these. And that's fine I think.
Distributors are obviously free to disregard the blessing.

> Michael and Scott's Customization process takes care of
>  some aspects of both of these questions,

I think the customization process will work in specific distribution
context. It's not the right solution for Sugar/Fedora or Sugar/Ubuntu,
for example.

> but it doesn't address the
>  question of whether or not Sugar would issue a release that was
>  incompatible with *any* Draw activity.

That's another reason the Sugar release should include activities imo.
It will give good criteria to decide when API changes are ready to be
released (yeah we should aim for API stability, but at some you always
need to break).

Marco