[Cuis] Fwd: Re: DIRECT version number
Phil (list)
pbpublist at gmail.com
Fri Jul 17 13:45:01 CDT 2015
On Fri, 2015-07-17 at 10:39 -0300, Juan Vuletich wrote:
> Additional stuff about versioning, and how to keep your code working
> as Cuis changes.
>
> Please share your ideas and thoughts about this.
>
> We all want to ease development and maintenance of all sorts of
> projects while allowing a moderate rate of change to Cuis itself...
>
> Cheers,
> Juan Vuletich
>
> -------- Original Message --------
> From:
> - Thu Jul 16 10:47:08 2015
> X-Mozilla-Status:
> 0001
> X-Mozilla-Status2:
> 00800000
> X-Mozilla-Keys:
>
>
> Message-ID:
> <55A7B5DA.1020103 at jvuletich.org>
> Date:
> Thu, 16 Jul 2015 10:47:06 -0300
> From:
> Juan Vuletich <juan at jvuletich.org>
> User-Agent:
> Mozilla/5.0 (Windows; U; Windows NT
> 6.1; en-US; rv:1.9.2.28)
> Gecko/20120306 Thunderbird/3.1.20
> MIME-Version:
> 1.0
> To:
> H. Hirzel <hannes.hirzel at gmail.com>
> Subject:
> Re: DIRECT version number
> References:
> <CAGQxfVgD-0tAQxe5bZkYEQX=aYYBLjETAdCpWHHU44Jy9m4WbA at mail.gmail.com> <55A7A607.7050304 at jvuletich.org> <CAGQxfVhi7=W5c8wZur7aLnKk_wRb=i9AQsFwCAaam02hcCiS3A at mail.gmail.com>
> In-Reply-To:
> <CAGQxfVhi7=W5c8wZur7aLnKk_wRb=i9AQsFwCAaam02hcCiS3A at mail.gmail.com>
> Content-Type:
> text/plain; charset=UTF-8;
> format=flowed
> Content-Transfer-Encoding:
> 7bit
>
>
> Hi Hannes,
>
> On 7/16/2015 9:57 AM, H. Hirzel wrote:
> > Thank you Juan, for answering.
> >
> > At the moment I feel uncomfortable using Cuis because it is currently
> > a quite fast moving target. I perceive quite a number of API changes
> > though this might be wrong. But I do not know because there are no
> > release notes which summarize it.
>
I totally feel Hannes' pain having gone through it a few times myself
over the years. At the same time, I agree with Ken's point about not
getting too bogged down in process since we're in the best position
right now to break things for the better longer term.
> Yes, that's true. Besides, we don't have a specification of what is an
> API and what is not. So, almost any change can be considered an API change.
>
That's the problem! Both for you and us (it's a general 'Smalltalk Way'
issue, not specific to Cuis) I believe it is largely fixable without
tons of documentation and tests: the use of private (categories or
method naming convention). Bernhard pointed out an existing capability
a few months ago
http://jvuletich.org/pipermail/cuis_jvuletich.org/2015-March/001784.html
While I personally like the idea of private categories, one of these
approaches should really be seriously considered.
Other than a few specific examples (i.e. mostly the base data types
including the Collection and Number class hierarchies which are pretty
mature and don't change all that much anyway) I would guesstimate that
<20% (probably closer to 10%) of the methods, and and unknown % of
classes (a significantly larger fraction though), should even be
considered public. If things were indicated as private that would
accomplish two things:
1) We could construct some simple tooling (some combination of up-front
warnings in the editor and/or a lint-type tester after the fact) that
would allow people to identify problematic calls within their code.
(i.e. just because it works now doesn't mean it always will if you keep
calling X, Y, Z...)
2) It would provide a way for people to know if something needs to be
discussed. i.e. 'In class X method Y is private but I need that type of
functionality' so you would know that there's a need and could consider
either making it public, and therefore supported, or rethinking its
implementation if you'd like to offer a better public API solution.
> I don't want you to feel uncomfortable. Let's work this out.
>
> > And I do not now in which state my stuff and the general Cuis stuff ist.
> >
> > I need a new 'base line', i.e. a release number to which I can refer
> > to when upgrading my code.
>
> Well, but we do have that. It is the update number. It is part of any
> Cuis image I've ever committed to the repo.
>
> The problem, I think, is not identifying well defined Cuis releases. The
> problem is knowing how updates could affect your code.
>
By narrowing the scope of what the public API is using private
designators, this dramatically reduces what you need to be concerned
with on this front. It's part of the reason that Apple, Google, and
even Microsoft are so adamant about public APIs these days. They dealt
with the pain of even major developers depending on private APIs for
decades. It's only been in the last 10 years or so that they've been
able to dig themselves out from under this issue.
This gets back to the 'Smalltalk Way' issue I referenced earlier. The
attitude of 'you have the source, play around, have fun!' has morphed
into 'everything is a public API! there are no rules! isn't this
great?' Well no, it's not great. It makes life impossible for image
maintainers (Squeak has been in a coma for the last decade or so as the
result of trying to keep everyone happy... yet no one seems to be) and
miserable for those who are trying to keep code running on it (stuff
still breaks all the time.)
I personally believe the minimalism and simplicity that Cuis is based on
has the best long term prospects but we have to get out of this
'everything is public' mindset. Sure, we have all the source: look at
it, learn from it, poke around, refactor it, submit fixes, etc. But
there needs to be a manageable subset of it which is considered the
'public API' that people can depend on to write frameworks and apps on
top of that is relatively stable longer term. Let's start defining what
that is and backfill changes to the public API (which will happen from
time to time as we don't want things to be completely static) with tests
and documentation so you can focus your efforts on where they matter
most and you get the most enjoyment from.
> > Of course the other option is to just follow the most recent update
> > all the time. That would call for some kind of continuous integration
> > testing 'Cuis style' which I not have either.
> >
> > E.g. if you could do a writeup how you do test Cuis before each new
> > commit (there are over 50 this year) and which scripts you use I could
> > apply the same thing for my packages.
> >
> > It has to be something which can be done quickly. Semi-Automatic is
> > fine. A check list with
> >
> > - do this
> > - then execute that script
> > - Open .. this and that
> > - And finally run a report on ...
> >
> > would be fine.
>
> I don't have that either. I run the tests from time to time (I'll start
> doing it before any commit, and add the xml report to the rep). But this
> is not the most important reason why Cuis is solid. Cuis is very
> reliable because:
reliable != stable
> - I'm not too bad as a coder.
> - I do my own code revisions at least one day after each change.
> - I use Cuis every day, and spot most problems in the updates, before
> commtting them to the repo.
> - I really, really care about code quality.
> - I think Cuis keeps Smalltalk-80 and its ideals alive. And I think that
> is a big responsibility, given how important I think Smalltalk-80 is.
>
Agree to all this and more. Cuis would not be where it is without your
continued effort and diligence. (i.e. setting aside that you obviously
created it, if you had just tossed it out into the world and let it go
at best it would have started looking something like Squeak or Pharo by
now. It's a lot of effort over the long term to *keep* it small and
focused. THANK YOU JUAN!)
> So, I suggest running your tests when updating your image, or migrating
> your code to an updated image.
>
+1 to tests as they do help quite a bit and are a very good practice.
Just be judicious in what/where you test (I personally don't subscribe
to the TDD approach where you spend your days mostly writing tests.
That's just admitting defeat in that you spend all day writing
executable documentation.)
> In any case, I think this doesn't answer your concerns. What you need is
> some way to know which updates could affect you, to review them in
> detail, and understanding their effect on your code. A list of the
> affected classes and/or methods for each update makes no sense. Cuis can
> already show you that very easily. Perhaps each update should include:
>
> 1) parts of the system that are affected:
> - Kernel
> - Compiler
> - Tools
> - Morphic
> - etc
>
> 2) Level of risk involved
> - very unlikely to break code that depends on this part of the system
> - could perhaps break code that depends on this part of the system
> - will most likely break code that depends on this part of the system
>
> Or something like that.
>
> BTW, this is a very relevant topic for discussing on the mail list. Feel
> free to answer there if you agree.
>
One final thought on this: I suspect a major cause of people abandoning
Cuis (and Smalltalk in general), behind the 'it's too different from
what I'm used to'/'not mainstream' reaction, is the instability of its
APIs.
> Cheers,
> Juan Vuletich
>
>
> > However doing a release tag in github is really not a big deal if you
> > actually take the plunge.
> >
> > You are not alone in not using this option.
> >
> > It took me two years to realize that I can learn to do it and actually
> > do a release in 5 minutes.....
> >
> > So I suggest do a release just continuing where you left off last time.
> >
> > Then people will start to realise there is something to test against.
> > And new update requests will come and you can do another one.
> >
> > So the release which I am asking for is not a big deal. Just a tag on a commit.
> >
> > I'd like to explore the direct authoring tools offered by Ken Dickey.
> >
> > With the aim of producing a very simple Hypercard / Powerpoint like
> > authoring environment.
> >
> > And do more with OMeta.
> >
> > Happy continued Cuis curating .....
> > And thank you very much indeed for your great work maintaining this environment.
> >
> >
> > Hannes
> >
> >
> >
> > On 7/16/15, Juan Vuletich<juan at jvuletich.org> wrote:
> >> On 7/12/2015 6:27 PM, H. Hirzel wrote:
> >>> Hi Juan
> >>>
> >>> Regarding a Cuis version number. I suggest that you just continue with
> >>> a new version number where you left off last time.
> >>>
> >>> It is just about having a version number to have a new baseline to
> >>> refer to. This is helpful for testing and documentation.
> >>>
> >>> I do not think it is a big issue.
> >>>
> >>> API changes require a new version number.
> >>>
> >>> Kind regards
> >>> Hannes
> >> Hi Hannes,
> >>
> >> Sometimes I don't pay enough attention to stuff like this, so feel free
> >> to request action from me when you feel appropriate :)
> >>
> >> Cheers,
> >> Juan Vuletich
> >>
>
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
More information about the Cuis
mailing list