Hi Stef! Thanks for the in-depth answers, some remarks/further questions:
> the update is only working for the core because OB is not part of > pharo but an add-on. > And the add-on are not managed by the pharo stream of changes but by > an update of > the projects in the pharo Universe (yes this is complex but we do not > want that people can > say that we are hijacking squeak tools). The motivation is fair, but the current solution seems untenable... I think we should consider cribbing from the model that Linux distros use: Load (more precisely: use -- we might not be able to load it) a / specific/ version of the Squeak tool, and then apply a separate (Pharo- maintained) set of patches to make it Pharo compliant. Define a process to specify how bug fixes are to be pushed upstream, and how enhancements are pulled downstream -- reassessing the Pharo patches each time a new version is pulled downstream. This way the tool is never hijacked but Pharo has a clear story on how it remains stable/unbreakable. If pushing bug fixes upstream is supported directly by tools we might even be able to make the argument that Pharo is helping the tool builders make better Squeak tools ;-) >> Pharo wants to be agile and be free to change at will (IMO a good >> decision) but if it is to be viable at my job there need to be >> versions that receive long-term support (the 'professional' aspect of >> Pharo). > > Yes > Normally with Squeak, severe bugs and selected one where retrofitted > in old versions. This way seaside 3.8 users got important fixes when > we did 3.9. It depends on how often Pharo wants to do a 'stable' release, if that is once every two years I don't see a problem with this model. But if that happens more often we will need to maintain a lot of older releases to make them viable for commercial use, thus spreading our resources thin. Hence my desire to pick only select releases that are designated to receive 'long term support' so bugfix back-porting efforts are concentrated on only one or two older releases to keep those alive for say 3+ years. [...for version management] > The vision is bytecode loader Pleas don't go there. Byte-code loading is a very nice-to-have in deployment scenarios (lazy plugin loading, live update delivery to deployed apps etc) but if there is one thing that using VW's Store has taught me it is that it definitely should not be part of a code repository that is used for development code version management. In the case of VW+Store standardizing on using only source-loading has served us well, it is definitely fast enough. Building our 'refactoring' image that holds all our projects (almost 100 MB image -- just code) takes less than an hour which is quite alright in a scenario where one uses nightly builds and updates the resulting image during the day-time development cycle. I suggest to get source-loading/diffing et al up to speed first. Cheers! Reinout ------- _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
