On Wed, Apr 1, 2009 at 11:12, Jonas Smedegaard <d...@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 <si...@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 _______________________________________________ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel