Re: DIRECT version number

> What I mean is this
>
> http://www.jvuletich.org/Cuis/CuisReleaseNotes.html
>
> New in Cuis 4.2 (released July 25, 2013)
>
>      Packages now have dependencies
>
>      Package loading greatly enhanced
>
>      Moved non-essential stuff to optional packages. Cuis is now below
> 500 classes and 100kLOC. Reduction was about 25%
>
>      Many bugfixes, and minor enhancements and cleanup
>
>
> NO RELEASE SINCE since July 2013!
>
>
> I suggest to do a release 4.3 soon and among other things have a
> clean-up  and documentation phase and then go for a 4.4 release after
> three months.
> I am willing to contribute to this.
>
> --HH
>
> On 7/16/15, H. Hirzel<[hidden email]>  wrote:
>> Thank you for the answer. Your conclusion nicely summarizes my concerns,
>>
>> I will think about it.
>>
>> As for no 1) parts of the system that are affected:
>>
>> Going for a list of all methods, taking the time stamp of last change
>> and do a graph of number of affected methods in each subsystem would
>> be helpful.
>>
>> That shows the impact of changes and allows to choose a proper commit
>> where I want to go for.
>>
>> That could be a built-in report.
>>
>> No 2) Level of risk involved
>> is more difficult to do automaticallyz
>>
>> --HH
>>
>>
>>
>>
>> On 7/16/15, Juan Vuletich<[hidden email]>  wrote:
>>> 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<[hidden email]>   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
>>>>>
>>>