> Keith, you know very well your main options:
> 1) 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.

> 2) 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