>
> As regards a given release, it seems to me the authority is fairly
> clear: the release team and perhaps more specifically the release team
> leader.  At that point of course the release team is in the position of
> having to guage the community's reaction to a change.  And here is where
> I think we have trouble in practice.  Our current methodology is to
> listen to the vocal minority (those who actually go to the trouble to
> post to squeak-dev or reply to the submitter).  My experience has been
> that it is those who feel negatively about something that feel most
> compelled to respond.  Correspondingly I strongly suspect there is a
> significant minority (at least) who is quite happy with the idea but
> either can't be bothered to respond or don't feel their opinion is
> relevant; then there's another quite possibly larger group who have no
> real opinion.
>
> Within this community I've come to feel that the only day to day
> practical solution is to do it and then ask for forgiveness when it goes
> all pear shaped (badly).  Of course when that happens it really helps
> when it is something that can be readily reversed with no harm done.
> And that's where it seems we have a problem because the current release
> management schemes don't well-support removing something readily and in
> such a way that few if any are inconvenienced.  I don't have a ready
> solution to that, it is something I find myself thinking about more and
> more.
>
> In the interim it seems to me that each release team has to make the
> choice.  They can either take a chance, make a change simply based on
> the vocal few and prepare for possible flames at a later date.  Or in
> cases where it seems desirable, go to a little more trouble and call for
> a semi-formal vote.  Clearly that's not something any of us want to do
> every week.  But I don't think it would be that big of a deal to do it a
> few times a year.  Details would need to be worked out but I think it
> would not be all that difficult and would be easier each time we did it.
>
> I have other thoughts on this and related issues, but I find myself
> getting more and more annoyed with long emails, and this one is already
> over the threshold,
>
> Ken
>
>

There is a solution: enable multiple versions of same package in same
image and keep track of package dependency.
So, when you loading an updated package, all code which worked before,
continues to work in same way as it was before.
We need a way to be able developer to choose, what parts of system can
use new version and what should use older version due to
incompatibility reasons by simply checking dependencies and updating
dependency links.

Also, this would help a lot in maintaining packages: a package author
can easily keep track of his package dependencies, and may or may not
wish to release his package with updated dependencies, which use
latest versions of packages, his package depends from.

Of course, this is somewhat idealistic, and there is many caveats, but
if done well, will allow us to mix things without fear that something
will not work due to incompatibilities.


-- 
Best regards,
Igor Stasenko AKA sig.