Proposal for a Squeak migration meeting

> Lex Spoon wrote:
>> Hilaire is only asking what the status and expectations about a  
>> usable
>> Tweak are.  It took a lot of asking, and apparently the answer is  
>> that
>> you have to go back and convert a 3.8 image to a Tweak one.  This is
>> different from Morphic, where Morphic was initially available in
>> Squeak right beside MVC.
>
> But what is your point, exactly? That Tweak is to blame for changes  
> in 3.9 that render 3.9 incompatible with 3.8 to such an extent that  
> Tweak doesn't work out of the box? Contrary to which other 3.8  
> based environments (iSqueak, Croquet, TinLizzie) run Tweak just fine.
>
> And for the records, the reason why Morphic was initially available  
> in Squeak right beside MVC was because the people who worked on it  
> (SqC) had control over BOTH. Unfortunately, the same cannot be said  
> about Tweak and 3.9 so unless your point is that you're screwed  
> when you don't have control over parts that you depend on (to which  
> I wholeheartedly agree), then I don't get the point you're trying  
> to make.
>
> Cheers,
>   - Andreas
>
>

> tim Rowledge <[hidden email]> writes:
>> On 7-Jul-06, at 6:48 AM, Bert Freudenberg wrote:
>>
>> [snip]
>> >
>> > Hilaire, it would be nice if you read what I write. I never said or
>> > implied that.
>>
>> It certainly would; putting words into other people's mouths is
>> neither polite nor hygenic.
>
> Hilaire is only asking what the status and expectations about a usable
> Tweak are.

> Am 10.07.2006 um 13:32 schrieb Klaus D. Witzel:
>
>> On Mon, 10 Jul 2006 10:05:48 +0200, Lex Spoon <[hidden email]>  wrote:
>>
>>> Hilaire is only asking what the status and expectations about a  usable
>>> Tweak are.
>>
>>
>> Thank you Lex, that was overdue! All that Hilaire wants is  confidence
>> on which GUI will be available for the next to come  project and/or
>> customer. Not a bad question to ask a community.
>
>
> Agreed, but it's not one with a simple yes/no answer like Hilaire  
> demanded, either.

>
>> Lex Spoon wrote:
>>> Hilaire is only asking what the status and expectations about a usable
>>> Tweak are.  It took a lot of asking, and apparently the answer is that
>>> you have to go back and convert a 3.8 image to a Tweak one.  This is
>>> different from Morphic, where Morphic was initially available in
>>> Squeak right beside MVC.
>>
>> But what is your point, exactly? That Tweak is to blame for changes in
>> 3.9 that render 3.9 incompatible with 3.8 to such an extent that Tweak
>> doesn't work out of the box? Contrary to which other 3.8 based
>> environments (iSqueak, Croquet, TinLizzie) run Tweak just fine.
>>
>> And for the records, the reason why Morphic was initially available in
>> Squeak right beside MVC was because the people who worked on it (SqC)
>> had control over BOTH. Unfortunately, the same cannot be said about
>> Tweak and 3.9 so unless your point is that you're screwed when you
>> don't have control over parts that you depend on (to which I
>> wholeheartedly agree), then I don't get the point you're trying to make.
>>
>> Cheers,
>>   - Andreas
>>
>>
>
>
>

>> Honestly, Stef, if it isn't random then what is the strategy for  
>> these
>> changes? Looking at the past Squeak versions, starting from 3.6 every
>> version was just incompatible enough with previous versions such  
>> that it
>> would break any serious user of the metaclass hierarchy (like  
>> Tweak). I
>> think you will agree that it can't continue that way, that at some  
>> point
>> we need to get back to what can be called a *stable* metaclass kernel
>> with reliable APIs and when exactly will that point be reached?
>
> To improve software, it is required to break backward compatibility.
> Nobody is forcing you to move to a new version.

>
> On Jul 10, 2006, at 4:22 PM, Julian Fitzell wrote:
>
>> I'm not saying don't break compatibility, I'm just saying be aware
>> every time that you are doing it.  And the thought that there be a
>> relatively stable API for a core set of classes that doesn't change
>> without some forethought is perfectly reasonable, in my opinion.  At
>> least then, when compatibility is broken, detailed instructions could
>> be provided on how to update your software in each case.
>
> Here, here. I'll add an example of the kind of incompatibility that I,
> at least, am frustrated by.
>
> I try to keep OmniBrowser compatible with Squeak 3.6 and later. Prior to
> 3.9, you can fetch a menu icon for delete operations by sending
> #deleteIcon to the class MenuIcons. In 3.9 you have to send
> #smallDeleteIcon. As far as I can tell, the change is completely
> gratuitous. The icon is small, yes, but there's no corresponding
> #largeDeleteIcon.  #deleteIcon was just removed, it wasn't changed to
> call through to #smallDeleteIcon or even deprecated.
>
> Apparently, I have to jump through some hoops to make menus work in
> Squeak 3.9 because somebody wanted to make the selectors more
> consistent. I'm all for progress, but this kind of thing is just
> irritating.
>
> Colin

> Lukas Renggli wrote:
>> To improve software, it is required to break backward compatibility.
>> Nobody is forcing you to move to a new version.
>
> For starters, let's get our basic assumptions right: This discussion
> isn't about people who do *not* want to move to new versions. It's
> about people who *do* want and what expectations they can have.
> Otherwise I'd agree with your statement.
>
>> If updates to the base-framework don't enhance anything in the
>> development process of your software, it is unnecessary to update. If
>> I were you, I would stick with 3.6. Still waters run deep.
>
> Well, if you were me, you would *want* to update. But you would have
> noticed that things got so inconsistently broken at the metaclass
> level that unless there are major pay-offs, it simply isn't worth the
> effort. That's what happened from 3.6 to 3.7. In 3.8 there was a major
> payoff - the m17n integration. That's why I then spent the time
> needed. For 3.9, from a Tweak POV there isn't that much interesting in
> there, so rather than going through the painful porting exercise yet
> again I'll probably spend my time on bootstrapping a stable
> (3.8-based) metaclass kernel which can be used in parallel to the 3.9
> kernel. Which is not particularly nice but in the absence of any
> inclination towards stable APIs the only alternative that I can see.
>
>> I have some legacy Seaside applications in ancient 3.6 images that run
>> just fine. They rarely change. They simply run fine. I won't port them
>> to 3.9 and a recent version of Seaside. These applications don't
>> require anything more as it is available in 3.6. However, for new
>> applications I take 3.9, I love
>> Shout/eCompletion/OmniBrowser/Traits/Pragmas/ToolBuilder/... I like to
>> keep up-to-date as long as it improves my productivity.
>
> You're totally missing my point. Let's take one example from your
> list: ToolBuilder. Let's say you've got some work that uses it, would
> you really expect that in each new Squeak version you have to spend
> major effort to port your code to the latest ToolBuilder version? Or
> wouldn't you rather expect that there is a stable API that can be used
> and that may be extended over time, or even broken, but if it's broken
> that you may get some notice about it beforehand? Or, in particular
> when the changes get really fundamental, that instead of modifying
> ToolBuilder in-place you get the offer to use either ToolBuilder
> (working the way it always did) and whatever the brand-new framework
> of the day is?
>
> I'm curious but is my position in this discussion really so outrageous?

>
> You're totally missing my point. Let's take one example from your
> list: ToolBuilder. Let's say you've got some work that uses it, would
> you really expect that in each new Squeak version you have to spend
> major effort to port your code to the latest ToolBuilder version? Or
> wouldn't you rather expect that there is a stable API that can be used
> and that may be extended over time, or even broken, but if it's broken
> that you may get some notice about it beforehand? Or, in particular
> when the changes get really fundamental, that instead of modifying
> ToolBuilder in-place you get the offer to use either ToolBuilder
> (working the way it always did) and whatever the brand-new framework
> of the day is?
>
> I'm curious but is my position in this discussion really so outrageous?

> Lukas Renggli wrote:
>> To improve software, it is required to break backward compatibility.
>> Nobody is forcing you to move to a new version.
>
> For starters, let's get our basic assumptions right: This  
> discussion isn't about people who do *not* want to move to new  
> versions. It's about people who *do* want and what expectations  
> they can have. Otherwise I'd agree with your statement.
>
>> If updates to the base-framework don't enhance anything in the
>> development process of your software, it is unnecessary to update. If
>> I were you, I would stick with 3.6. Still waters run deep.
>
> Well, if you were me, you would *want* to update. But you would  
> have noticed that things got so inconsistently broken at the  
> metaclass level that unless there are major pay-offs, it simply  
> isn't worth the effort. That's what happened from 3.6 to 3.7. In  
> 3.8 there was a major payoff - the m17n integration. That's why I  
> then spent the time needed. For 3.9, from a Tweak POV there isn't  
> that much interesting in there, so rather than going through the  
> painful porting exercise yet again I'll probably spend my time on  
> bootstrapping a stable (3.8-based) metaclass kernel which can be  
> used in parallel to the 3.9 kernel. Which is not particularly nice  
> but in the absence of any inclination towards stable APIs the only  
> alternative that I can see.
>
>> I have some legacy Seaside applications in ancient 3.6 images that  
>> run
>> just fine. They rarely change. They simply run fine. I won't port  
>> them
>> to 3.9 and a recent version of Seaside. These applications don't
>> require anything more as it is available in 3.6. However, for new
>> applications I take 3.9, I love
>> Shout/eCompletion/OmniBrowser/Traits/Pragmas/ToolBuilder/... I  
>> like to
>> keep up-to-date as long as it improves my productivity.
>
> You're totally missing my point. Let's take one example from your  
> list: ToolBuilder. Let's say you've got some work that uses it,  
> would you really expect that in each new Squeak version you have to  
> spend major effort to port your code to the latest ToolBuilder  
> version? Or wouldn't you rather expect that there is a stable API  
> that can be used and that may be extended over time, or even  
> broken, but if it's broken that you may get some notice about it  
> beforehand? Or, in particular when the changes get really  
> fundamental, that instead of modifying ToolBuilder in-place you get  
> the offer to use either ToolBuilder (working the way it always did)  
> and whatever the brand-new framework of the day is?
>
> I'm curious but is my position in this discussion really so  
> outrageous?
>
> Cheers,
>   - Andreas
>