> >> 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...
Yes > > 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. but only the developer of the tool can do that. > 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 ;-) :) >>> >> >> 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. we could see that. It also depends on the pace of changes. because Pharo 1.0 got a lot of deep changes like closures. I do not expect that huge changes in the future. > 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. Yes I see. > [...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. This is in VW store is bad. I do not see why a package MCZ could not ship with a byte-code synchronized version of the source. Then we could have a stripper or a synchronizer that recompile the source code and produce new bytecode. > 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. we will start by fixing packageInfo stef _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
