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