Talk:Development Team/Release/0.82

I've posted this email exchange as I think it gives a good rationale for the Activity release process. --Walter 17:16, 13 May 2008 (UTC)

On Tue, May 13, 2008 at 6:41 PM, Walter Bender <walter.bender@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