[Sugar-devel] [IAEP] [ANNOUNCE] Sucrose 0.88.0 Stable Release

Jonas Smedegaard dr at jones.dk
Thu Apr 1 18:24:08 EDT 2010

On Thu, Apr 01, 2010 at 05:24:08PM -0400, Walter Bender wrote:
>On Thu, Apr 1, 2010 at 1:43 PM, Jonas Smedegaard <dr at jones.dk> wrote:
>> Hi Walter (and others).
>> On Thu, Apr 01, 2010 at 12:07:55PM -0400, Walter Bender wrote:
>>> On Thu, Apr 1, 2010 at 12:00 PM, Jonas Smedegaard <dr at jones.dk> wrote:

>>>>  * Do newest release of Browse work on 0.84?
>>> I believe the answer is yes.
>> Specifically for 0.84 I believe that some activities only supports 
>> the "redesigned toolbar", and judging from its Git source branching 
>> Browse is one of those.
>Hmm. I was pretty sure that Browse had support for both styles of 
>toolbars. But apparently I am mistaken. As Peter mentioned, the 
>database in ASLO keeps track of which versions of which activities go 
>with the various Sucrose releases. I suppose those data should be in 
>the wiki somewhere as well, at least for Fructose.

I understand that, but see a difference between what is *available* (at 
ASLO) and what is *included* (as core Sugar).

I now found partly what I was looking for in the Roadmap pages:


Above pages contain at the bottom lists what appears to be release team 
approved lists of libraries and applications part of each major release.

What I still miss is a similarly authoritative version ranges - 
similarly to the lists at these pages:


Also it would be great if http://wiki.sugarlabs.org/go/0.84/Roadmap was 
updated to clarify if the "Proposed modules" was later rejected or are 
now officially part of Sugar since some minor version of 0.84.

>>>>  * Is (newest releases of) jukebox and imageviewer part of 0.84?
>>> The maintainers of 0.84 would have to answer this question. They are 
>>> doing quite a bit of backporting.
>> The question here was not if it _works_ with 0.84, but instead if it 
>> is considered as _part_ of the "core" Sugar environment.  So when you 
>> mention backporting efforts, I suspect that we are not talking about 
>> the same thing - or perhaps your use of "backporting" is what I would 
>> call "deriving".
>I mean backporting in the sense that they are taking a number of
>patches made for 0.88 and applying them to 0.84. So the definition of
>"core" Sugar for 0.84 is a bit of a moving target. Not being a distro
>person, I can only imagine that leading to some confusion, but for the
>most part, the backporting is confined to strategic bug fixes as
>opposed to redefinitions of components. There is a particular focus on
>0.84 because it is being rolled out on the new OLPC hardware and in
>many of the larger Sugar deployments.

I guess that's what I call backporting as well.  What confused me (now 
that I reflect a bit more on it) is not the "backporting" term, but the 
very act of backporting into a stable release, rather than aside it.

Debian has logic of not introducing new features into a branch after it 
has been released as "stable".

In other words, it is simply me being too used to thinking in Debian 
logic here :-)

  - Jonas

* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136  Website: http://dr.jones.dk/

  [x] quote me freely  [ ] ask before reusing  [ ] keep private
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
Url : http://lists.sugarlabs.org/archive/sugar-devel/attachments/20100402/6dad6d08/attachment.pgp 

More information about the Sugar-devel mailing list