Migrating from 6.0.2 to V8

[totallyobjects]

I know I should have done this a long time ago but issues with AbtTimestamp always put me off, even though I new how to fix them.

However, I am now trying to migrate a complex retail package including WebConnection from 6.0.2 to V8. However, I am having problems because the window applications all have AbtRunWinCwContolsApp as a pre-requisite and this doesn't exist in V8. I can't find any mention of this as a migration issue so can anyone point me in the right direction to resolve this?

Thanks in advance.

David

[koschate]

It is actually mentioned as a migration issue. The guide doesn't seem to be exhaustive in terms of what you need to do for going to x to y - you actually have to look at all the intermediate version migrations as well. In this case, have a look at the "Migrating from 7.5" section.

[wembley]

Thomas -

That is correct. You start reading with the chapter of the Migration Guide covering migration up from your existing version and you keep reading until you get to the end. We tried to make this clear by including:

After you complete any needed migration steps mentioned in this chapter, you should continue to the subsequent chapters of this document to review further migration requirements.

at the beginning of each chapter, but I guess if you are just scanning the Contents navigation area for a key phrase, you would miss that.

[koschate]

I guess if you are just scanning the Contents navigation area for a key phrase, you would miss that.

Developers are an impatient lot. We don't want to waste time reading intermediate steps - we want all the information in one place!

[wembley]

Thomas -

This book is the hardest one to write because we sometimes only think we know what the issues are. Then, when the code hits the street, we are sometimes surprised by an unforseen side effect of some change. However, unlike when IBM was developing this product, we are committed to keeping the information in the Migration Guide as accurate, current, and useful as possible. I totally reorganized the Migration Guide so that it reads from front to back (rather than the IBM version that read from back to front ) and information that was stashed away in dark corners regarding migration from earlier releases has been added.

Anyway, if you have any suggestions about how we could make the Migration Guide more useable, I would be happy to hear them.

[koschate]

I realize it's a tough problem, and I appreciate the amount of information that has been surfaced. A slight change in the wording at the start of each section might help. Currently, there's a sentence that reads "This chapter addresses concerns for users of VA Smalltalk Vx.x who are migrating to the current release of VA Smalltalk. " A quick read of that sentence would suggest that the section is not of interest to users migrating from versions prior to x.x. A possible alternative: "This chapter addresses concerns for users of versions of VA Smalltalk prior to who have completed the previous migration steps, and current users of VA Smalltalk Vx.x to who are migrating to the current release of VA Smalltalk." (I've been reading too many EULAs! ).

Another nice feature would be a separate page for each version of VA Smalltalk that provides a summary of all the steps needed to migrate to the current version. Essentially, this is the same as the initial page of each section, but combining the initial pages of all sections involved in migrating from x.(x-y) to x.x. Obviously there would be redundancy, but there's a lot of value in having a single page reference that can be used as a migration checklist.

[wembley]

Thomas -

How about (for example):

This chapter addresses migration concerns for users of VisualAge Smalltalk V5.5 or earlier who are migrating to the current release of VA Smalltalk.

or:

This chapter addresses migration concerns for users of VisualAge Smalltalk V5.5, and users of earlier versions who have completed the previous migration steps, who are migrating to the current release of VA Smalltalk

which I don't think reads as well, but is more accurate, and:

After you complete any needed migration steps described in this chapter, you should continue to the subsequent chapters of this document to review further migration requirements.

as a near-term 'course correction'?

For a longer-term approach, perhaps we could try turning each of the existing chapter introduction pages into a checklist that would include a list of all migration steps needed when migrating from that release to the current release (with links to the details as is there now). Them we could collect all the detail pages in a single chapter, arranged in some useful way. This reorg (or something similar) would not be a high-priority change (in my mind, at least) and is not something I can promise, but something we could evaluate.

[koschate]

While wordier, I like the second option better than the first. I think these changes are a good starting point.

[wembley]

Thomas -

OK, I'll wait a bit to see if anyone else chimes in with suggestions before I make the changes.