[Sugar-devel] Distributors mixing across Sugar branches (Was: Terminal v25 (attention distro managers!!))

[Morgan Collett]

On Wed, Apr 1, 2009 at 11:12, Jonas Smedegaard <dr at jones.dk> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Wed, Apr 01, 2009 at 10:12:07AM +0200, Tomeu Vizoso wrote:
>>On Tue, Mar 31, 2009 at 22:55, Simon Schampijer <simon at schampijer.de> wrote:
>>> Wade Brainerd wrote:
>>>> Yeah, v24 introduced tabs.  v25 is a bugfix of v24.
>>>
>>> Hmmm, it has been packaged for Fedora 11 already. And F11 should only
>>> contain Sucrose 0.84. Please make clear what Sucrose version it is
>>> for when you announce new releases - since otherwise packagers pick
>>> it up and put it in 0.84?
>>
>>Wonder if that's a problem for SugarLabs? If a packager wants to
>>include an activity that is not part of the stable release of Sugar
>>that they are shipping, isn't that their choice?
>
> I'd say so too.
>
> What I see that Sugarlabs can do to help encourage distributors to not
> "fuck up" is to more clearly document what breaks by mixing.
>
> I have been guilty of mixing: Debian 0.82-based packages contain a "too
> new" Browse. That activity will not run on an XO, but Debian contains a
> newer underlying library so it works proberly anyway (I believe).  But I
> couldn't find anywhere a list of what I would break by mixing - I
> learned about this particular shortcoming by following this upstream
> development list closely, until someone mentioned it. (I think I even
> posted an explicit question about it at somepoint, which I think was
> ignored).
>
> I am not complining here, not at all: If we distributors mess your
> carefully composed dependencies, then we are to blame for breaking
> anything.  But your carefull composition is based on some assumptions of
> the underlying OS which are not universally true, and so does not apply
> to all versions of all distributions.
>
>
> - From a distributor point of view, it would be nice to be able to look at
> the Homepage of each part of Sugar (sugar-toolkit, sugar-base, sugar,
> hulahop, Browse, etc) and see not only a download link for the latest
> and greatest release of that piece, but a download link for the latest
> and greatest release for *each* of your development tracks (i.e.
> currently 0.82, 0.84 and "bleeding edge") and also a brief note on which
> changes are not backwards-compatible.

+1

Also publishing the changelogs for each release would be good -
currently they seem to be only sent in the release announcement mail.

Regards
Morgan