AW: [PEAR-DEV] [RFC_v3] Handling Backwards Compatibility in PEAR [hopefully the final draft]

Pierre-Alain Joye wrote: [..] > > Don't agree. You seem to always think about dedicated server > > environments but what if a hoster has 1000+ users/server > and only 40 > > rely on package XY which API now has changed. > > I do not. And I think this hoster should think to install > only the core. Yes you _think_. It _should_ be that way - O.K. That are a little too much assumptions for my taste. > His users can then install whatever packages they need in > their tree, both can live together, having core in the common > part and userland packages in another, as far as it allows to > change the include path (if he does not I wonder why he still > get tousands of user ;) ). Good suggestion - O.K. Maybe there should be a PEAR for hosters document. Don't expect every hoster to dive into PEAR and see how things can be done. > > Just thing about TreeMenu. If the API changes all websites > using it to > > create the navigation will stop to work. > > Now have fun migrating 40 sites at once in one night. > > The hoster won't ever be able to migrate to the new version. > > Explain me what will make you upgrade it suddenly only > because a new major version has been released? Did you not > see the previous alpha/beta before? Sorry - maybe I'm wrong but how should I ever migrate to beta if it overwrites the stable package? It's IMHO exactly the same case as with a stable package. regards Daniel Khan