[Cuis] Fwd: Re: DIRECT version number

Fri Jul 17 08:39:47 CDT 2015

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.

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.

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.

>  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:
- 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.

So, I suggest running your tests when updating your image, or migrating
your code to an updated image.

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.

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
>>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20150717/bf76dfe7/attachment-0003.html>