Re: DIRECT version number

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: DIRECT version number

Juan Vuletich-4
(cc the mail list)

Yes, we could do it. I kinda stopped doing "releases" because with a
constantly updating GitHub repo, each commit can be considered a "release".

So, the question is,
What is a release? How is it different from a GitHub commit?
What is the value of a release?

Maybe it is just about following a tradition (from the time of diskettes
and CD Rom). Or maybe it is about crating echos in other places (tweets,
blogs, etc)...

What do others think?

Cheers,
Juan Vuletich

On 7/16/2015 4:36 PM, H. Hirzel wrote:

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


_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
Reply | Threaded
Open this post in threaded view
|

Re: DIRECT version number

KenDickey
On Fri, 17 Jul 2015 10:03:16 -0300
Juan Vuletich <[hidden email]> wrote:

> So, the question is,
> What is a release? How is it different from a GitHub commit?
> What is the value of a release?

IMHO, a Release is a stable point, expected to be robust and with some level of support, which one can develop against without concern for the ground changing under one's feet.

This is important in commercial projects and things one likes to demo and share around.

In particular, I would expect a Release for Cuis to have major associated packages also maintained at that particular release level.  It would be good to package the core release and associated packages matching that release together.

At this point, I test most of my packages with many (not all) Cuis Commits so that I can find/fix breakage as it happens.  I expect to do this.  I want Cuis to change for the better, radically, but I am not keeping a set of packages pegged to a historical Release.

I am willing to do maintain versions my packages for a particular Cuis release, e.g. for stable demos.  However, I would prefer Releases to be a long intervals (say a year) or after some radical change has been introduced and stabilized.

So far, this has not been a problem, but as usage increases ...

$0.02
-KenD

_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
-KenD