Keith, you know very well your main options:
- you take a trunk/pharo/cuis image then reload all your stuff
(LPF/Installer/Sake/Package SHOULD be helpful). You may report compatibility problems in relevant list.
yep, correct.
- you start with an unmaintained image from the past, transform MC
diffs into change sets and you cherry pick, but you're on your own.
yep correct again.
So points to conclude from this.
a. Everyone is on their own.
b. You can't really start doing either, until the 3.11 is released. (So a bi-monthly release cycle would be a better thing than a bi- annual one, I am still waiting for the process that is going to get us a bi-monthly release, tested and documented)
c. If you do start doing it now, you have to continuously track trunk. If you use packages form pharo, you probably have to continually track pharo as well!
d. The packages that you publish which have existing users, you either have to maintain a dual codebase for, one for the old and one for the new base images, or you have to restrict yourself to the lowest common denominator. (if you are forced to do this all the time, then there is no point in moving to a better api)
I know very well your problems. I played option 2) during seveal years when releasing a commercial product in VW. I know very well the costs, and I know you are in trouble with this path.
You are making the mistake that option 1 and 2 are mutually exclusive, they are not.
You only have to back port essential API changes, (like for example, if Pharo publish Author as a loadable package that would load into Squeak, then a load of compatibility problems will be sorted)
Once you have back ported the API, you can move your own code base forward, and continue to support other users still stuck in the past, by offering them the backport patch.
Not that many experienced people are still supporting option 2). Juan still use it because he wants a very fine grain control. The fact that Cuis is minimal may help but he knows how much time it costs. Sorry, but I doubt you'll attract many people on that path.
And the evidence we have is that purely relying on option 1, leaves a trail of forks behind it, (etoys, sophie cobalt, and now soon to be an orphan "beach") for which the cost of porting up to the front is 3 months of unproductive work. Secondly there are now two fronts to port up to, so which do you choose?
All that is needed is to facilitate a migration path, from 3.x to 3.x +1. Note I didn't say you need to provide that migration path, just facilitate it.
You facilitate it by packaging separate innovations separately upfront. (like we did on mantis, but on a less granular scale). This is the basis of the packaging model, just applied to features of the kernel. Then you build your releases by integrating innovations on a regular basis.
Then the knowledge you need to backport an innovation is there if you need it. No cherry picking is needed. Secondly you are not on your own, because if you extend the innovation to provide a backport to say, 3.10. Edgar can come along and contribute his knowledge (by conceptually subclassing your work) and extend it to work for "Minimal" too.
So the model proposed is: you innovate in the latest release, in your context, but you don't publish your innovation in such a way as to restrict its use to only your context. (that would normally be called a changeset (cs), or a deltastreams-delta (ds) You allow others to retarget your innovation to their context, and you provide a place where all users of that innovation pool their knowledge as to how to apply your innovation to all the different contexts. This is what Sake/ Tasks is for, you provide your innovation as one Task, with dependencies and pre-requisites, and others can subclass that Task to tweak it for application to other contexts, which have other dependencies and pre-requisites.
Sake/Packages does this for packages. It collects the data as to what is needed to load a package into Squeak, Pharo, and any other contexts you care to add. However it does this, not just for the current releases, but also past unmaintained releases. The squeaksource.com/ Packages repository becomes a shared resource defining exactly what loads where. If for example I want to load a package into a released version of Minimal, then I can add the fix to the the dependencies in the Minimal packages definitions. At a later date I hope I can persuade Edgar to incorporate the patch in Minimal, but if there are any users of the old Minimal release then they will still need the patch.
Would I develop an app today, no doubt it would be with option 1. Installer/Sake could be used as well for option 1, couldn't it ? You
Yes this is what I use, and have used since 2006.
1. However pier keeps data in image, so the move is not routine. 2. Trunk is still moving, and is alpha so it will not be ready for at least 6 months and i wont have the time for perhaps a year to do it (so trunk remains irrelevant to me for all practical purposes until about a year or more hence) 3. I am not just porting an application to latest, I am supporting packages that have users in many images. So while I may port my stuff to latest, I still have to support my users in 3.x-1. So I end up having to follow option 2 anyway, even to achieve option 1.
The bob process would only integrate release quality finished innovations into the final-release. Conceptually there would never be an alpha release, there is always a stable release X, and the previous stable release X-1, and the 100 or so deltas that move X-1 to X.
have to think about this option too. That's how I see things with option 1:
- you select an image when you think added value is worth the effort
(like faster file I/O)
- you load and run specific Kernel tests expressing the essential
expectations of your application here, you can have a go/no go decision. It can also be a maybe: you send requests to developpers or propose your own changes in trunk.
Its a bit late, since I wont be starting this until 6 months after trunk is released.
- you play your scripts to load your application
- you run your application tests and ask for support on regressions
and uncompatibilities.
But meanwhile I still have to support and maintain the X-1 release. So I still have to back port patches to X-1.
We have a mechanism for patching the current release (its called the release team), but we don't have a mechanism for patching the X-1 release for my existing package users. (that is what LPF was invented for, but if no one uses LPF....)
More over, with bob you could automate the tests and automatically know if trunk updates are breaking things or not.
yep you could.
So the question of an officially "released" image is less relevant. If you really want this process, adopt Pharo, they are close to 1.0
Thats what I was actually thinking of doing, until I actually tried pharo, and discovered they had removed the PackagePaneBrowser. I find OB unusable.
(without faster streams and other improvments of course...).
Cheers.
Nicolas
Keith