<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Hi Nico,<br>
<br>
On 1/6/2022 9:22 AM, Nicolás Papagna Maldonado via Cuis-dev wrote:
<blockquote
cite="mid:CADGn7BOFoRUMW29H-G-jLn2n1q_mS3E0BEykSQZ6L04RBUkOVg@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>Hi Juan!</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Wed, Jan 5, 2022 at 6:34
PM Juan Vuletich <<a moz-do-not-send="true"
href="mailto:JuanVuletich@zoho.com">JuanVuletich@zoho.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin: 0px 0px 0px
0.8ex; border-left: 1px solid rgb(204, 204, 204);
padding-left: 1ex;">
<div bgcolor="#ffffff"> Hi Nico,<br>
<br>
On 1/5/2022 5:12 PM, Nicolás Papagna Maldonado via
Cuis-dev wrote:
<blockquote type="cite">
<div dir="ltr">I second Mariano's request!
<div><br>
</div>
<div>I don't really know what should I do to fix my
packages.</div>
</div>
</blockquote>
<br>
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...<br>
</div>
</blockquote>
<div><br>
</div>
<div>Thanks for the clarification. That helped a lot to
understand how these kinds of changes are merged/released.</div>
</div>
</div>
</blockquote>
<br>
Good!<br>
<br>
<blockquote
cite="mid:CADGn7BOFoRUMW29H-G-jLn2n1q_mS3E0BEykSQZ6L04RBUkOVg@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_quote">
<div> </div>
<blockquote class="gmail_quote" style="margin: 0px 0px 0px
0.8ex; border-left: 1px solid rgb(204, 204, 204);
padding-left: 1ex;">
<div bgcolor="#ffffff"> <br>
<blockquote type="cite">
<div dir="ltr">
<div>Related to that, please check an email I sent a
couple of days ago ("[Proposal] Keep a changelog").</div>
<div>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.</div>
</div>
</blockquote>
<br>
Agreed. Anyone can volunteer to do that by following the
GitHub commits and this email list.<br>
<br>
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.<br>
<br>
</div>
</blockquote>
<div><br>
</div>
<div>My apologies if what I wrote sounded like a demand (it
was a proposal), that was not my intention.</div>
<div>Yup, I was aware of that and agree 100%. </div>
<div><br>
</div>
<div>Sadly, in the case of keeping a changelog, volunteering
won't work IMHO. </div>
<div>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.</div>
</div>
</div>
</blockquote>
<br>
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.<br>
<br>
<blockquote
cite="mid:CADGn7BOFoRUMW29H-G-jLn2n1q_mS3E0BEykSQZ6L04RBUkOVg@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_quote">
<div>I'd expect that people submitting changes to contribute
to the changelog as well (at least that's how I see the
volunteer part).</div>
<div>Having someone else do that doesn't sound right to me
(lack of context, doubling the effort required, etc).</div>
</div>
</div>
</blockquote>
<br>
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.<br>
<br>
<blockquote
cite="mid:CADGn7BOFoRUMW29H-G-jLn2n1q_mS3E0BEykSQZ6L04RBUkOVg@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_quote">
<div>Anyways, if this is not an issue (or maybe for a few),
then there is nothing to be fixed :)</div>
<div><br>
</div>
<div>Cheers!</div>
<div>Nico PM</div>
</div>
</div>
</blockquote>
<br>
The issue obviously exists. It is perhaps the biggest problem in
software development. See, for instance how several major projects
deal with it:<br>
- 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.<br>
- 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.<br>
- Windows: Give back compatibility for very (really VERY) long time.<br>
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.<br>
<br>
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.<br>
<br>
Still, there is room for improvement, new ideas and initiatives.<br>
<br>
Discussing these issues is necessary for a healthy process and
community. Thanks for raising the subject.<br>
<br>
Cheers,<br>
<pre class="moz-signature" cols="72">--
Juan Vuletich
<a class="moz-txt-link-abbreviated" href="http://www.cuis-smalltalk.org">www.cuis-smalltalk.org</a>
<a class="moz-txt-link-freetext" href="https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev">https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev</a>
<a class="moz-txt-link-freetext" href="https://github.com/jvuletich">https://github.com/jvuletich</a>
<a class="moz-txt-link-freetext" href="https://www.researchgate.net/profile/Juan-Vuletich">https://www.researchgate.net/profile/Juan-Vuletich</a>
<a class="moz-txt-link-freetext" href="https://www.linkedin.com/in/juan-vuletich-75611b3">https://www.linkedin.com/in/juan-vuletich-75611b3</a>
<a class="moz-txt-link-freetext" href="https://independent.academia.edu/JuanVuletich">https://independent.academia.edu/JuanVuletich</a>
@JuanVuletich</pre>
</body>
</html>