So fixes are not integrated into the image anymore and the report then closed?
When a release image is released the fixes are integrated into the image as normal, and can be closed or marked "fixed".
Release image? that means, you will not close *any* bug-report until you release 3.11? Wow. But you sure close at least duplicated bug-reports?
Everything that I have been developing loads into "all" existing images, so for example, LPF may want to load fixes into 3.7 if it needs something.
So does this make sense? I think there is not enough manpower to even get *one* stable and *one* development branch going. Beeing backtward compatible to such old releases makes no sense. Especially as 3.7 is very different to 3.9 (just the I18N stuff will kill you). In the end, what you are doing will result in kind of re-doing 3.8 for 3.7, 3.9 for 3.8... and so on, in addition to actually doing 3.11. Is that realistic?
Previously fixes are ONLY available by waiting for the release team to harvest, or by manually loading a changeset in yourself. Now the harvesters can make a fix readily available for everyone through Installer.
This attitude of supporting all users of squeak, while moving things forward for everyone, is a core-value of the 3.11 team.
This is *the* recipe for failure. You can not do anything even remotely complex if any changeset that fixes something in 3.11 needs to work on 3.7, too.
What I don't understand with the use of Installer with mantis entries: From my experience from 3.6 to 3.9, there is quite some dependency between fixes. Nothing is automatic, if you or some script loads the wrong fix in the wrong order then that is a problem.
And of course this means that nobody can load any other order, so it makes no sense to have all the fixes as entities on their own at all.
to build "your own release". This just can't work with all the dependencies between fixes.
However, the old way, fixes are applied to a moving target, since the alpha image is continuously being updated.
Yes, this is very important. As loading a fix for 3.10 into the developement version of 3.11 will almost never work, as other fixes already changed the sytem. This is true even with the installer. So you will end up in using the "moving target" of 3.10+ Intaller as your "HEAD" system that people use when doing changes. Else you will end up in many changesets that have conflicts, and, very annoyting, hundreds of douple-reports of bugs.
With this approach fixes applied to 3.10 (a fixed target) are used to create a 3.11 unstable until the combination of fixes is deemed "stable"
But this can not work: fixes depend on each other. It is *one of the most important principles* to let the submitter of fixes do the work of merging his fix with the latest fix applied to the image. Else you will die. You can never manage the amount of changes submitted if you can just say: "rejected. reason: conflicts with current version. Please resubmit". Another very important principle is to close reports on the bugtracker as soon as possible to keep it managable. This even means that once a changeset is harvested, the report is closed *and not re-opend* if there is a new bug after applying. That is a *new* report, for a *new* bug (the report then will of course refrence the faulty closed report). Overall, I am 100% sure that your idea how to manage 3.11 is fundamentally wrong (sorry). And Pharo will do it completely differently: release often, integrate as soon as possible, keep the bugtracker down to managable levels and do not be religiously backwards-compatible. We will see at the end what was the better Idea ;-) Marcus -- Marcus Denker -- denker@iam.unibe.ch http://www.iam.unibe.ch/~denker