Hi, there.
If there are only the latest packages in the Squeak 4.6 repository, there may be many important mcm-checkpoints (together with postLoad-migration-scripts) are missing. Updating a busy 4.5 image to 4.6 might fail easily. Don't we want to support that? Best, Marcel |
Hmmm.... It's a good question. I, personally, have never wanted to
do that (upgrade 4.n ---> 4.n+1), because a new release image is the best time to get a new clean image for my own applications to make sure I can actually build inside the new image. The only disadvantage I can see to your proposal is the duplicating about 1000(?) mcz's to take up more space on disk.. unless making soft links (hard links?) would solve that..? On Sat, Jun 6, 2015 at 3:21 AM, marcel.taeumel <[hidden email]> wrote: > Hi, there. > > If there are only the latest packages in the Squeak 4.6 repository, there > may be many important mcm-checkpoints (together with > postLoad-migration-scripts) are missing. Updating a busy 4.5 image to 4.6 > might fail easily. > > Don't we want to support that? > > Best, > Marcel > > > > -- > View this message in context: http://forum.world.st/Updating-Squeak-4-5-to-Squeak-4-6-tp4830777.html > Sent from the Squeak - Dev mailing list archive at Nabble.com. > |
At the moment, 4.5 updates to 4.6 (trunk) just fine. I was wondering how our CI server could generate a working 4.6 release image based on an older release image.
However, I think there are no things running in the CI base image and thus it might just work out fine. :-) Best, Marcel |
On 07.06.2015, at 13:56, marcel.taeumel <[hidden email]> wrote:
> > At the moment, 4.5 updates to 4.6 (trunk) just fine. I was wondering how our > CI server could generate a working 4.6 release image based on an older > release image. > > However, I think there are no things running in the CI base image and thus > it might just work out fine. :-) We’ve never tried supporting a direct upgrade between releases. If someone wants to spend time on that then fine, but the only disadvantage of doing it via trunk updates is that it runs for a bit longer, right? - Bert - smime.p7s (5K) Download Attachment |
On Mon, 8 Jun 2015, Bert Freudenberg wrote:
> On 07.06.2015, at 13:56, marcel.taeumel <[hidden email]> wrote: >> >> At the moment, 4.5 updates to 4.6 (trunk) just fine. I was wondering how our >> CI server could generate a working 4.6 release image based on an older >> release image. >> >> However, I think there are no things running in the CI base image and thus >> it might just work out fine. :-) > > We’ve never tried supporting a direct upgrade between releases. If someone wants to spend time on that then fine, but the only disadvantage of doing it via trunk updates is that it runs for a bit longer, right? stop at a given .mcm, and tag some .mcms as releases. That way we can use the Trunk repository to upgrade from one release to another. Levente > > - Bert - > > > > |
On Mon, Jun 8, 2015 at 9:54 AM, Levente Uzonyi <[hidden email]> wrote: --
I think you're also implying that a release can be defined by a specific update map right? So we could have update-Squeak46.NNN.mcm and update.spur-Squeak50.NNN.mcm, which also allows supporting bug fix releases, e.g. update-Squeak461.NNN.mcm and update.spur-Squeak501.NNN.mcm. I like this. Levente best,
Eliot |
Free forum by Nabble | Edit this page |