Why isn't Squeak 4.1 updating?

> On Mon, 19 Apr 2010, Casimiro de Almeida Barreto wrote:
>
>> Hello,
>>
>> Why isn't squeak 4.1 updating?
>
> Because the Update URL preference is set to
> http://source.squeak.org/squeak41 .
> If you want the changes from the trunk, change the url to
> http://source.squeak.org/trunk .

>
>
> Levente
>
>>
>> Best regards
>>
>> CdAB
>>
>>
>
>

>
> On 4/19/2010 5:18 PM, Casimiro de Almeida Barreto wrote:
>> Ok, bad phrased question. Real question is: setting preferences to
>> http://source.squeak.org/trunk will keep compatibility with future
>> updates of squeak41 ???
>
> That's pretty much a given. It would be weird to have incompatible changes between 4.1 fixes and current trunk development. Not impossible but highly unlikely.
>
> Cheers,
>  - Andreas

>
> Em 20-04-2010 06:04, Bert Freudenberg escreveu:
>> (...)
>> Well, maybe I misunderstood the question, but I expect to see changes in trunk that you would not want to see in 4.1. It's our current stable release (btw, someone should update Wikipedia) so if packages are posted to the 4.1 repository, they would not simply be taken from trunk. They would be carefully selected, high-impact fixes only.
>>
>>
> Most things in trunk are enhancements, updates and fixes. Perhaps
> enhancements won't go to 4.1 if they're found inconvenient or useless
> but till now I haven't seen back steps. I see trunk as a kind of
> Fedora's rawhide and I understand that I will eventually find alpha/beta
> stuff stuff inside that will be replaced in next updates. That's not a
> problem for me.
>> I guess I don't know what "compatibility" means in this discussion ...
>>
> Among other things, compatibility means that something was present
> before updates and disappear after them (missing/renamed
> methods/messages for instance) so packages that were working just stop
> to do so. Changes in behavior also impact compatibility.

> Em 20-04-2010 09:27, Bert Freudenberg escreveu:
>> (...)
>>
>> It could well be that methods that were deprecated before are finally removed in trunk. We cannot promise full backwards-compitibility forever, otherwise we would have no chance of ever getting a cleaner system.
>>
>>  
> Ok. Nothing is compatible forever... not even C/C++ things over time.
>> What would help immensely is if we could define what APIs we consider to be stable and supported. These need to be documented, and changes would need to be documented for each new release too.
>>  
> As a tip, besides external documentation it would be convenient if
> deprecated classes and methods/messages got commented ("Deprecated:
> will/may be removed in next releases"). Also comments like
> "Experimental: behavior may change in next updates" and "Alpha"/"Beta"
> would be useful.

> On 20.04.2010, at 05:03, Andreas Raab wrote:
>>
>> On 4/19/2010 5:18 PM, Casimiro de Almeida Barreto wrote:
>>> Ok, bad phrased question. Real question is: setting preferences to
>>> http://source.squeak.org/trunk will keep compatibility with future
>>> updates of squeak41 ???
>>
>> That's pretty much a given. It would be weird to have incompatible changes between 4.1 fixes and current trunk development. Not impossible but highly unlikely.
>>
>> Cheers,
>> - Andreas
>
> Well, maybe I misunderstood the question, but I expect to see changes in trunk that you would not want to see in 4.1. It's our current stable release (btw, someone should update Wikipedia) so if packages are posted to the 4.1 repository, they would not simply be taken from trunk. They would be carefully selected, high-impact fixes only.
>
> I guess I don't know what "compatibility" means in this discussion ...
>
> - Bert -
>
>
>

> On 20.04.2010, at 14:17, Casimiro de Almeida Barreto wrote:
>>
>> Em 20-04-2010 06:04, Bert Freudenberg escreveu:
>>> (...)
>>> Well, maybe I misunderstood the question, but I expect to see changes in trunk that you would not want to see in 4.1. It's our current stable release (btw, someone should update Wikipedia) so if packages are posted to the 4.1 repository, they would not simply be taken from trunk. They would be carefully selected, high-impact fixes only.
>>>
>>>
>> Most things in trunk are enhancements, updates and fixes. Perhaps
>> enhancements won't go to 4.1 if they're found inconvenient or useless
>> but till now I haven't seen back steps. I see trunk as a kind of
>> Fedora's rawhide and I understand that I will eventually find alpha/beta
>> stuff stuff inside that will be replaced in next updates. That's not a
>> problem for me.
>>> I guess I don't know what "compatibility" means in this discussion ...
>>>
>> Among other things, compatibility means that something was present
>> before updates and disappear after them (missing/renamed
>> methods/messages for instance) so packages that were working just stop
>> to do so. Changes in behavior also impact compatibility.
>
> It could well be that methods that were deprecated before are finally removed in trunk. We cannot promise full backwards-compitibility forever, otherwise we would have no chance of ever getting a cleaner system.
>
> What would help immensely is if we could define what APIs we consider to be stable and supported. These need to be documented, and changes would need to be documented for each new release too.
>
> Maybe that's what Casey signed up for? ;)
>
> - Bert -
>
>
>