[Cuis] Fwd: Re: DIRECT version number

[Ken.Dickey]

On Sun, 19 Jul 2015 20:39:31 -0400
"Phil (list)" <pbpublist at gmail.com> wrote:

> The issue is what constitutes a major change?  If your code uses it it's
> major, if mine uses it it's minor?  Coin toss?  Without a public API
> what is considered major is either obvious (i.e. Morphic changes from
> global to local coords or changing the File/Directory API so obviously
> everything using them breaks) or arbitrary (sorry to hear that you
> depended on that... but it wasn't major, now it's gone)  If the image
> snapshot is considered the public API, then everything must be both
> considered fair game to depend on and to change in the future which is
> unmanageable.

I don't think this is the issue at all. 

The text editor comes up in every release with goals for Cuis.  Backward compatibility is a stated non-goal.

I am happy to baseline my packages a couple of times a year against a baseline core release and maintain such matched baseline package releases.

I trust Juan's leadership and judgment. His time is a scarce and valuable resource.  He is very responsive to the Cuis community, including requests for backward compatibility and additional support.  I do _not_ want to slow him down.

If you have specific requirements, a package with Feature/Unit-tests is a good way to express this.

> I'm not trying to restrict Juan in any way from making the changes he
> thinks are important for Cuis.  His taste and direction have been
> generally excellent and the reason I'm here!  If for example, he decides
> that #drawOn: is no longer the way to do things or that even Morph
> needed to go away, that's fine as long as what's going on gets
> communicated.  However, a problem I think he faces right now is that he
> doesn't know who's using / depending on what.

Pardon me, but this sounds exactly like you are trying to restrict certain changes.

It seems that you are trying to "plan" and "rule set" rather than "discover quickly".

My experience is that quick discovery (like writing unit tests and running them very frequently) is the fastest development path.

My guess is that major packages which prove useful will either migrate into the core packages or will be tested against as part of a larger release process.  I just prefer that process to be as small and painless (low drag) as possible.

If some package is not in wide use, the author can test against releases as often as he/she feels it necessary.  We can deal with breakage as it arises rather than planning search strategies for avoiding breakage.  For me, this is much more efficient.

Having API test suites is a good way to communicate importance.


As an aside, I have found some breakage to be very enlightening and (sometimes painfully) helpful.  I heard that the Arabic word for "miracle" literally translates to "breaking the habit".  Interesting thought.

In the limit, we may be "agreeing loudly" here.  Easy to sound strident in an email.  Not the intent.


What is the simplest thing that will work?
-KenD