[Squeakfoundation]RE: Your stewardship(s)

[Daniel Vainsencher]

[API changes breaking compatibility]
This will make having package releases much more important. Then users
could ignore the problems by tracking a configuration that is
compatible. The more breakage pain there is, the more conservative
configuration builders will be.

As you say, on the developers' side, conventions like private categories
should be used, and frameword developers should start thinking of their
APIs as semi-obligations, to be broken as rarely as possible.

I think we can treat this whole subject lazily - we'll solve the problem
when pain becomes common. I've personally had an API changed under me
already (By PackageInfo), but I think it's still rare enough it's not
worth addressing with Infrastructure or Rules.

Daniel

Andreas Raab <andreas.raab at gmx.de> wrote:
> Göran,
> 
> > > With SM, we need a more declarative style that tells both, 
> > > clients and framework developers which methods can be relied
> > > upon and which can't.
> > > Without this, maintaining a package simply becomes a nightmare.
> > 
> > Are you sure? I mean, don't you think a little bit of 
> > documentation on a package might suffice? So that it is
> > obvious what classes/messages are meant to be used from
> > outside? And if we combine this with a more unit
> > test centric model perhaps it would be enough.
> 
> Honestly, I doubt it. The working style doesn't go that way. If you are a
> user of some package you need to read the documentation first. That's fine
> as far as it goes. But then you start screwing around and see that "perfect
> method" which solves your problem immediately. And so you use it. There's
> nothing in the _code_ that tells you "don't use me, I am private to that
> package and using me means you're doomed to fail a couple of releases down
> the road". The same on the other end. If you're a package developer you have
> to constantly go to a different place and update your documentation. And
> naturally, you will forget to do this because it's awkward. If you want to
> solve this problem by documentation then this documentation must be
> intrinsically linked to the code involved. And once you do that it _is_
> essentially a more declarative style of programming - even if you would put
> it into comments (which I wouldn't).
> 
> Also, the big issue with "all remote senders" which you were proposing is
> not the fact that you can find those senders. Again, that's fine but the
> problem is you can't _fix_ them. And that means you have to rely on the
> implementors of that other package that they only use what you have declared
> to be the "public API" which brings us back to the above issue. At this
> point you could in fact say that everyone who uses any "private messages" to
> that package be screwed but you can carefully phase out obsolete public
> messages without the fear to break anything that has been written according
> to your design (e.g., using public messages).
> 
> The key issue is that both implementors and clients of a framework need to
> be able to tell what interfaces exactly they can rely on. If you can't tell
> this, handling large decentralized packages _will_ be a nightmare before
> long. We cannot expect people to lock-step in the development if those
> packages are individually developed, we cannot rely on having that "large
> synchronized base" (e.g., monolithic image). If we want to allow evolution
> then we must find a model of determining what we promise to support "long
> term" (e.g., across minor versions) and what we don't.
> 
> Cheers,
>   - Andreas
> 
> _______________________________________________
> Squeakfoundation mailing list
> Squeakfoundation at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/listinfo/squeakfoundation