[Cuis] Fwd: Re: DIRECT version number

[Phil (list)]

On Mon, 2015-07-20 at 06:55 -0700, Ken.Dickey wrote:
> 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.
> 

The first issue (text editor working in every release) is the difference
between reliability and stability, at least as I've been meaning in this
discussion.  Yes, it works in every release because it is part of what
is at least implicitly tested to a degree as part of nearly every build.
Cuis is very reliable in that within a given build things are generally
working better than they did in the previous build.

The backward compatibility non-goal seems like it should decrease as
Cuis matures. (not sure if this is a recent change or not, but it
actually does say that on the Cuis home page)  Once we hit a minimal
feature set, backwards incompatibility should largely go away as the
result of a combination of Cuis becoming the simplest thing that would
work and diminishing returns.  Perhaps we disagree on how close to that
point we are?  As Juan indicated, at some point the packages start to
play a larger role and at some point the same stability discussion
becomes an issue there as well.  (At least if the plan is to be able to
build larger and more complex things using Cuis in the future)

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

In theory what you're saying makes sense but in practice I didn't find
it worked.  I tried that back in the 2.x days and again in 4.x but found
the release notes just didn't have the detail to make this work for me.
I disliked the results enough that I'm currently trying to stay within a
build or two of Juan but that isn't realistic to expect most people to
do (I don't think so, at least) and if I ever fall behind in the current
model, I'm screwed...

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

I agree.  The question is how do we accomplish this.  My sense is that
we are starting to chew up more of his time peppering him with
questions / issues that he didn't anticipate resulting from recent
changes.  At the same time, for those who are not staying on the
bleeding edge, there is a level of frustration in that we're living in
an environment with very few constants and some of the changes have been
starting to hurt.

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

I guess I see explicitly identified public methods and
feature/unit-tests as being complementary and helping lead to the same
place.

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

Poor choice of wording on my part, I probably should have said something
like 'prevent'.  Putting any sort of limits on when / how changes can be
made is a restriction.  But I'm not actually asking him to *not* make
the changes he thinks are necessary, but manage the when / how in some
cases.

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

I am asking him to plan a bit more *only* for a subset of things that we
agree need to be more stable than the rest.  I still believe that is <
20% of the unique method names.
  
> 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.

I don't think that most people will accept the compatibility through
continual testing/fixing over a long period of time... most will likely
give up after experiencing this for a while if they're attempting to use
Cuis as something more than a playground.

If the long term objective *isn't* for Cuis to be a platform, then an
acceptable answer would be 'you're using it wrong'.  Or Juan could
simply say 'yeah, ok... but I really don't want to do that...'

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

I know you're generally pretty level headed and not looking to be
disagreeable.  I engaged in this discussion because it is an important
one to have and it felt like the right time to have it. A lot of what is
being proposed is a change from how things have historically been.  But
at the same time the pace of change has slowed down (ah, those whirlwind
1.x and 2.x days... :-) so it *seems* like trying to start to try to
stabilize things a bit has relatively little downside.  (Dunno... maybe
Juan is working on chucking the whole Magnitude hierarchy or something
major like that right now...)

> 
> What is the simplest thing that will work?
> -KenD