Difference between revisions of "Talk:Development Team/Release/0.82"
(New page: I've posted this email exchange as I think it gives a good rationale for the Activity release process. --~~~~ On Tue, May 13, 2008 at 6:41 PM, Walter Bender <walter.bender@gmail.com> wrot...) |
m |
||
| Line 17: | Line 17: | ||
I think we should just be flexible in this respect: | I think we should just be flexible in this respect: | ||
| − | * In the normal case maintainers of activities included in the Sugar | + | * In the normal case maintainers of activities included in the Sugar release process should be willing to follow the schedule, i.e. provide |
| − | 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. |
| − | development and stable releases more or less in sync with the Sugar | + | * If there is a need to skip a development cycle (for example because the developers are working on large features or refactoring of the |
| − | 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. | code) it's fine to do so. | ||
| − | * Activities are encouraged to release stable updates outside the | + | * Activities are encouraged to release stable updates outside the Sugar dev cycle when there is need to do so. |
| − | Sugar dev cycle when there is need to do so. | ||
:> In some cases, there is more than one choice for a core activity: | :> In some cases, there is more than one choice for a core activity: | ||
Revision as of 14:18, 13 May 2008
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