[Cuis-dev] Renaming several fundamental Morph classes

[Juan Vuletich]

Hi Nico,

On 1/6/2022 9:22 AM, Nicolás Papagna Maldonado via Cuis-dev wrote:
> Hi Juan!
>
> On Wed, Jan 5, 2022 at 6:34 PM Juan Vuletich <JuanVuletich at zoho.com 
> <mailto:JuanVuletich at zoho.com>> wrote:
>
>     Hi Nico,
>
>     On 1/5/2022 5:12 PM, Nicolás Papagna Maldonado via Cuis-dev wrote:
>>     I second Mariano's request!
>>
>>     I don't really know what should I do to fix my packages.
>
>     See my response to Mariano's email. The Cuis update mechanism was
>     designed to make it easy to follow changes. Compare, for instance,
>     with .mcz non human readable files...
>
>
> Thanks for the clarification. That helped a lot to understand how 
> these kinds of changes are merged/released.

Good!

>
>>     Related to that, please check an email I sent a couple of days
>>     ago ("[Proposal] Keep a changelog").
>>     I believe that would make the life of all of us who want to
>>     improve Cuis a little easier when this kind of change happens.
>
>     Agreed. Anyone can volunteer to do that by following the GitHub
>     commits and this email list.
>
>     Please keep in mind this is a volunteer community. Nobody pays for
>     anything, and therefore nobody is a customer. Nobody charges for
>     anything, and therefore nobody provides customer service. And this
>     is a project aimed at Smalltalk developers and serious students.
>     People is expected to be willing to study the system. If in doubt,
>     give a read to README.md in the main repo, and
>     CodeManagementInCuis.md in the Documentation folder.
>
>
> My apologies if what I wrote sounded like a demand (it was a 
> proposal), that was not my intention.
> Yup, I was aware of that and agree 100%.
>
> Sadly, in the case of keeping a changelog, volunteering won't work IMHO.
> The whole point of it is to have a single, reliable source of truth to 
> check for breaking changes and have a summary of what changed since 
> the last release.

Yes, but a reliable source of truth is something that can not be done. 
Any change may have unforeseen consequences, especially if the code base 
can not be bound! I think the whole software industry is essentially 
just examples of that. We could talk about formal specifications, but 
that only moves the problem to a more esoteric level, where it is even 
harder to deal with.

> I'd expect that people submitting changes to contribute to the 
> changelog as well (at least that's how I see the volunteer part).
> Having someone else do that doesn't sound right to me (lack of 
> context, doubling the effort required, etc).

I think that what can be done with a reasonable effort on everyone 
involved is the kind of stuff we already do: use descriptive names for 
the update change sets, and reasonable commit messages. Additionally, 
changes that are perceived as risky or with likely impact on existing 
code are discussed in the mail list. Finally, all packages in the 
Cuis-Smalltalk organization are updated when a non-compatible change is 
done, and our CI runs all the tests in the base image.

> Anyways, if this is not an issue (or maybe for a few), then there is 
> nothing to be fixed :)
>
> Cheers!
> Nico PM

The issue obviously exists. It is perhaps the biggest problem in 
software development. See, for instance how several major projects deal 
with it:
- MacOS: Explicitly guarantee back compatibility for a small number of 
years. Deprecate stuff, but support it for a while. Remove unsupported 
stuff. Any application using them will break.
- Linux / Debian / Ubuntu: Additinally maintain separate LTS releases 
(long term support). Give users the choice of being closer to the 
bleeding edge or prefer longer term stability.
- Windows: Give back compatibility for very (really VERY) long time.
Each option gives better back compatibility than the previous one, at 
the price of a more complex code base, higher development cost, and more 
limited room for evolution.

I started Cuis as a one person effort, and as a reaction of the very 
limited evolution Squeak was having. I made a conscious decision to 
sacrifice back compatibility to enable evolution and to reduce 
complexity. Almost twenty years later, Cuis has grown to a community 
project, and evolution has been slowing down as Cuis matures. All this 
is great indeed! But, from time to time, evolution might mean somewhat 
breaking compatibility. As I said before, we don't do this lightly, and 
we do spend a reasonable effort in limiting damage. I believe that the 
current process distributes the burden in a somewhat reasonable way, and 
that the sum of all the efforts we all need to do to make progress 
happen is close to the minimum.

Still, there is room for improvement, new ideas and initiatives.

Discussing these issues is necessary for a healthy process and 
community. Thanks for raising the subject.

Cheers,

-- 
Juan Vuletich
www.cuis-smalltalk.org
https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev
https://github.com/jvuletich
https://www.researchgate.net/profile/Juan-Vuletich
https://www.linkedin.com/in/juan-vuletich-75611b3
https://independent.academia.edu/JuanVuletich
@JuanVuletich

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20220106/5aef0a5d/attachment.htm>