Michael Latta wrote:
We can add tools that support our
> work, far more effectively than in many other environments.  If the rate 
> of change is too high for some packages to keep up on a release-by 
> release basis, then have fewer major releases, and more releases for 
> testing within the community.  For example rather than doing 3.9 with 
> all components, release a 3.8.5 with those components that can be ported 
> to the next core release.  When all the packages are caught-up than call 
> it 3.9, or the like.  Have intermediate releases that are for "internal" 
> use to get new technologies in the image and people working with it.  Or 
> simply extend the alpha/beta periods, whatever.  We can also create 
> tools that make it easier to know if a package is impacted by changes.

yes, lots of good ideas here.

another important thing IMHO would be to have at any time a clear idea 
of which part of the system is supposed to be reliable on the very long 
term, and them make all necessary efforts to ensure full backward 
compatibility for packages solely based on this reliable part.


Stef