RE: RE: Your stewardship(s)

[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 <[email protected]> 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
> [email protected]
> http://lists.squeakfoundation.org/listinfo/squeakfoundation
From [email protected] Mon Mar 10 15:34:07 2003
Return-Path: <[email protected]>
Delivered-To: [email protected]
Received: (qmail 31286 invoked from network); 10 Mar 2003 15:34:07 -0000
Received: from concorde.inria.fr (192.93.2.39)
  by mail.theinternetone.net with SMTP; 10 Mar 2003 15:34:07 -0000
Received: from tif.inria.fr (tif.inria.fr [128.93.11.73])
	by concorde.inria.fr (8.11.1/8.11.1) with ESMTP id h2AFY6f04357
	for <[email protected]>;
	Mon, 10 Mar 2003 16:34:06 +0100 (MET)
Received: from localhost (piumarta@localhost)
	by tif.inria.fr (8.8.8/8.8.8) with ESMTP id QAA00402
	for <[email protected]>;
	Mon, 10 Mar 2003 16:34:04 +0100 (MET)
Date: Mon, 10 Mar 2003 16:34:04 +0100 (MET)
From: Ian Piumarta <[email protected]>
To: Discussing the Squeak Foundation
	<[email protected]>
Subject: Re: [Squeakfoundation]3.5 release timing (was Re: Outstanding 3.4
 bugs?)
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-BeenThere: [email protected]
X-Mailman-Version: 2.1
Precedence: list
Reply-To: [email protected], Discussing the Squeak Foundation
	<[email protected]>
List-Id: Discussing the Squeak Foundation
 <squeakfoundation.lists.squeakfoundation.org>
List-Unsubscribe: <http://lists.squeakfoundation.org/listinfo/squeakfoundation>,
	<mailto:[email protected]?subject=unsubscribe>
List-Archive: <http://lnx-12.ams-2.theinternetone.net/pipermail/squeakfoundation>
List-Post: <mailto:[email protected]>
List-Help: <mailto:[email protected]?subject=help>
List-Subscribe: <http://lists.squeakfoundation.org/listinfo/squeakfoundation>,
	<mailto:[email protected]?subject=subscribe>
X-List-Received-Date: Mon, 10 Mar 2003 15:34:07 -0000

On Sun, 9 Mar 2003, Tim Rowledge wrote:

> Doug Way <[email protected]> wrote:
> 
> I'll just raise again my objections to the idea that it is possible to
> do any sensible beta in only a couple of weeks and any plausible gamma
> ditto.

I agree with Tim.  In fact I think I would generalise this to say thay
imposing a hard timeline on any [potentially unbounded] activity is a
risky business.  Why not plan the release cycle around the notion of
outstanding unfixed bugs, rather than on hard deadlines?  That way the
_state_ of the system drives the releases, rather than vice-versa.

Last wek somebody mentioned bug tracking system.  If we had one, with a
notion of "critical bugs", "invonveniences", and "cosmetic fixes" for
example, then something like this (starting from the last stable release)
might make sense:

PAR

  SEQ

   - decide what new stuff wants to be in (or taken *out* of the system
     and put into a SM package) in the next release

   - make a new image and tag it as "alpha"

   - invite all concerned to hack on the changes

   - when things have settled down, tag the image as beta and
     make it available for download for anyone who wants to
     help with beta testing

   - wait for the bug reports to come flooding in ;)

2: - fix bugs (of any and all priorities)

   - while (critical bugs != 0) sleep(several days); goto 2

   - tag the image as "gamma" or "release candidate" or
     whatever, and then announce it for public consumption
     on all the lists and invite each and every Squeaker
     to give it a go

   - sleep (a week or two)

3: - while (critical bugs remain): fix bugs; post updates;
     sleep(a few days); goto 3

   - tag the image as final and release it

  ENDSEQ

  SEQ

   - collect new feature requests for the next stable release

  ENDSEQ

ENDPAR

Ian