[vwnc] Store - reset version number
Locked
[vwnc] Store - reset version number
 
|
Hi
With a store version browser one can select a version and reset the blessing level. Is there any way to select a version and change its version number? My reason for this is that one would like configuration packages to have version numbers that track releases. However, one may want to only bump a version level if at first it passes a set of tests. But, you need to assign it a version number to simply produce a frozen configuration. As it stands now you would have to load and republish just to bump the version level. By bumping the version level I mean; you start with 7.6.3.12 and if it passes the tests it becomes 7.6.4. Terry =========================================================== Terry Raymond Crafted Smalltalk 80 Lazywood Ln. Tiverton, RI 02878 (401) 624-4517 [hidden email] <http://www.craftedsmalltalk.com> =========================================================== _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: [vwnc] Store - reset version number
|
|
I don't believe that there's any tool support for doing
that. You'd have to use something like the Store Workbook in
StoreForGlorp, or else just go into the database and change it. It's a
pretty safe operation as far as going into the database and just altering
rows goes.
At 07:21 PM 2009-11-02, Terry Raymond wrote: Hi --
Alan Knight [|], Engineering Manager, Cincom Smalltalk
_______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: [vwnc] Store - reset version number
|
|
Alan:
> It's a pretty safe operation as far as going into the database and > just altering rows goes. There's a gotcha though, when updating an existing StorePackage (or StoreBundle) you MUST do: existingPundle trace: existingPundle trace. Otherwise, the prior version becomes unhooked And So It Goes Sames ______________________________________________________________________ Samuel S. Shuster [|] VisualWorks Engineering, Store Project Smalltalk Enables Success -- What Are YOU Using? _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: [vwnc] Store - reset version number
|
|
In reply to this post by Terry Raymond
Dear Terry,
as Alan and Sames, remark, you can use Glorp to rename but must be careful to preserve the versions relationship to its parent, since the code is set up on the assumption that changing the version is part of a cloning activity. Now that Store runs on Glorp in VW7.7,. version renaming may become a menupick in a future release. Meanwhile, the following script can be run in a Store workbook (opened on the package owner's login or an administrator login, or a login for anyone with appropriate permissions in the DB) to rename while avoiding loss of parent info. | wrongVersionPundle | wrongVersionPundle := (session read: StorePackage where: [:each | each name = 'ThePackageName' & (each version = 'TheWrongVersionString')]) first. session inUnitOfWorkDo: [session register: wrongVersionPundle. wrongVersionPundle previous: wrongVersionPundle previous. wrongVersionPundle version: 'TheRightVersionString']. session reset. Obviously, use caution in applying scripts to your store data; if you edit it using hacked Glorp scripts instead of tested menu-driven code, you may corrupt your data. Yours faithfully Niall Ross >Hi > >With a store version browser one can select a version and reset the blessing >level. Is there any way to select a version and change its version number? > >My reason for this is that one would like configuration packages to have >version numbers that track releases. However, one may want to only bump a >version level if at first it passes a set of tests. But, you need to assign it a version >number to simply produce a frozen configuration. As it stands now you would >have to load and republish just to bump the version level. > >By bumping the version level I mean; >you start with 7.6.3.12 and if it passes the tests it becomes 7.6.4. > >Terry > >=========================================================== >Terry Raymond >Crafted Smalltalk >80 Lazywood Ln. >Tiverton, RI 02878 >(401) 624-4517 [hidden email] ><http://www.craftedsmalltalk.com> >=========================================================== > > >_______________________________________________ >vwnc mailing list >[hidden email] >http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > > > > _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: [vwnc] Store - reset version number
|
|
In reply to this post by Terry Raymond
Every time this version rename discussion comes up it is followed by the late realization that "oh yeah, other users of our shared code repository already loaded versions that had been renamed; how does their trace version get fixed?". Developers don't know the (now renamed) version they'd based their changes on. When they reconcile to the wrong version (because their loaded version had been renamed) and review their changes before publishing there is some chance they'll mix up changes and mistakenly reverse changes made and integrated by others. Whoops.
A version rename is safe in some situations that may apply to you. There is never a need to change a version number when you use a good numbering system and release tools. Paul Baumann -----Original Message----- From: [hidden email] [mailto:[hidden email]] On Behalf Of Terry Raymond Sent: Monday, November 02, 2009 7:21 PM To: VWNC Subject: [vwnc] Store - reset version number Hi With a store version browser one can select a version and reset the blessing level. Is there any way to select a version and change its version number? My reason for this is that one would like configuration packages to have version numbers that track releases. However, one may want to only bump a version level if at first it passes a set of tests. But, you need to assign it a version number to simply produce a frozen configuration. As it stands now you would have to load and republish just to bump the version level. By bumping the version level I mean; you start with 7.6.3.12 and if it passes the tests it becomes 7.6.4. Terry =========================================================== Terry Raymond Crafted Smalltalk 80 Lazywood Ln. Tiverton, RI 02878 (401) 624-4517 [hidden email] <http://www.craftedsmalltalk.com> =========================================================== _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc This message may contain confidential information and is intended for specific recipients unless explicitly noted otherwise. If you have reason to believe you are not an intended recipient of this message, please delete it and notify the sender. This message may not represent the opinion of IntercontinentalExchange, Inc. (ICE), its subsidiaries or affiliates, and does not constitute a contract or guarantee. Unencrypted electronic mail is not secure and the recipient of this message is expected to provide safeguards from viruses and pursue alternate means of communication where privacy or a binding message is desired. _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: [vwnc] Store - reset version number
|
|
In reply to this post by Terry Raymond
On 03/11/09 11:21, Terry Raymond wrote:
> By bumping the version level I mean; > you start with 7.6.3.12 and if it passes the tests it becomes 7.6.4. > This isn't what you were after, but I'd probably look at a slightly different way of managing versions and release numbering. I'd probably go with one of two options: 1) Display the whole version string to the user, so if 7.6.3.12 is released to the users, that's what they see. or, if you don't want to display such a long version string to the users, or perhaps you want to include the version in the release notes and don't want to have to keep updating it with every minor change just prior to release, then 2) Only display the first three numbers of the version string to the user and keep the 4th number for development use only. If going with option 2, it would mean that while doing work toward the release of 7.6.4, your version strings would be 7.6.4.11, 7.6.4.12.... That way there's nothing to bump. If 7.6.4.12 passes the tests, it's released and is seen by the users as 7.6.4. The very next publish after the release has been done would then be as 7.6.5.1. If a bug is filed against 7.6.4, you known that you need to look at the highest numbered 7.6.4.x publish, which you could also have set the blessing level on just to be sure. Anyway, that's how I'd handle versioning, others might have better ways. David _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: [vwnc] Store - reset version number
|
|
In reply to this post by Paul Baumann
The trace does not depend on the name, so I don't think
changing the name would affect people who had loaded the version. At
least they won't lost the version. Their image may think that version
ought to be called something different, so it might, for example, suggest
the wrong name when you went to publish, but I don't think you'd run into
a situation where they loaded from the repository and the information is
lost.
But I agree that there are other ways to handle those scenarios, and we don't do renames internally. At 05:12 PM 2009-11-03, Paul Baumann wrote: Every time this version rename discussion comes up it is followed by the late realization that "oh yeah, other users of our shared code repository already loaded versions that had been renamed; how does their trace version get fixed?". Developers don't know the (now renamed) version they'd based their changes on. When they reconcile to the wrong version (because their loaded version had been renamed) and review their changes before publishing there is some chance they'll mix up changes and mistakenly reverse changes made and integrated by others. Whoops. --
Alan Knight [|], Engineering Manager, Cincom Smalltalk
_______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
[vwnc] Branches as objects (was: Store - reset version number)
|
|
In reply to this post by Paul Baumann
I think the problem of wanting to reset version numbers arises from a
deficiency in Store which does not allow to distinguish between revision numbers (which should be fixed) and branch/release labels (which should be changeable -- at least until the branch gets closed, which would be another new concept). Currently we mix up revision numbers and branch/release labels within the single version number Store offers. To take Terry's example, the versions 7.6.3.0, 7.6.3.1, ... 7.6.3.12 all belong to the branch intended for developing 7.6.4, so why not extract that into its own abstraction with the name "7.6.4" and with its own blessing level to indicate its status? The versions formerly called 7.6.3.0, 7.6.3.1, ... would just be the revisions 0,1 ... of that branch. I would like to see Store support this by extracting the notion of branch into an object. The branch would have a fixed branch number, a label which can be changed and it would contain revisions which are just numbered within the branch starting at 0. A revision would be identified by <branch number>.<revision number within that branch>. Prerequisites would use this version number to reference special versions or ranges of versions (it might make sense to allow branch labels as well -- especially if branch names become fixed when the branch gets closed). Then you would just start a new branch and add revisions to that branch. The branch would have the label 7.6.4. When it passes the tests you would change the blessing level of the *branch* to indicate that. In case of deciding that 7.6.4 should be skipped because marketing decided to release 8.0 instead :-), you would just relabel your branch to 8.0 (this works the other way around, too: say after releasing 7.6.3 you started work on 8.0 and then have to deliver the current development state as patch 7.6.4, then you might just relabel the branch, test it, close it with a blessing level to Released and start a new branch for 8.0). Having branch objects would make other things possible: for example you could display a graph where the nodes represent branches which would be much clearer than the graph of all versions. Selecting a branch would display a list of the revisions it contains besides the graph. Being able to close branch objects would make it explicit when a branch has been finished either by a release, by a dead end or by a final integration into another branch. The latter case currently cannot be distinguished from integrating the current state of the branch. Dead branches currently cannot be marked except by setting the blessing level of each version belonging to the dead branch. Just an idea. Best regards Thorsten Thorsten Seitz Development Center BahnNet I (T.SID 31) DB Systel GmbH Raum 5C.124, Alfred-Herrhausen-Allee 1, 65760 Eschborn Tel. 069/265-48245, intern 955- _________________________________________________________________________________ Internetauftritt der Deutschen Bahn AG >> http://www.db.de Sitz der Gesellschaft: Frankfurt am Main Registergericht: Frankfurt am Main, HRB 78707 USt-IdNr.: DE252204770 Geschäftsführer: Detlef Exner (Vorsitzender), Norbert Becker, Dr. Burkhard Klanke, Dr. Klaus Rüffler Vorsitzender des Aufsichtsrates: Dr. Rolf Kranüchel |-------------------------------------> | Paul Baumann | | <[hidden email]>| | Gesendet von: | | [hidden email] | | | | | | 03.11.2009 23:12 | |-------------------------------------> >-------------------------------------------------------------------------------------------------------------------------------| | | | | | An| | "'Terry Raymond'" <[hidden email]>, VWNC <[hidden email]> | | Kopie| | | | Thema| | Re: [vwnc] Store - reset version number | | | | | | | | | | | >-------------------------------------------------------------------------------------------------------------------------------| Every time this version rename discussion comes up it is followed by the late realization that "oh yeah, other users of our shared code repository already loaded versions that had been renamed; how does their trace version get fixed?". Developers don't know the (now renamed) version they'd based their changes on. When they reconcile to the wrong version (because their loaded version had been renamed) and review their changes before publishing there is some chance they'll mix up changes and mistakenly reverse changes made and integrated by others. Whoops. A version rename is safe in some situations that may apply to you. There is never a need to change a version number when you use a good numbering system and release tools. Paul Baumann -----Original Message----- From: [hidden email] [mailto:[hidden email]] On Behalf Of Terry Raymond Sent: Monday, November 02, 2009 7:21 PM To: VWNC Subject: [vwnc] Store - reset version number Hi With a store version browser one can select a version and reset the blessing level. Is there any way to select a version and change its version number? My reason for this is that one would like configuration packages to have version numbers that track releases. However, one may want to only bump a version level if at first it passes a set of tests. But, you need to assign it a version number to simply produce a frozen configuration. As it stands now you would have to load and republish just to bump the version level. By bumping the version level I mean; you start with 7.6.3.12 and if it passes the tests it becomes 7.6.4. Terry =========================================================== Terry Raymond Crafted Smalltalk 80 Lazywood Ln. Tiverton, RI 02878 (401) 624-4517 [hidden email] <http://www.craftedsmalltalk.com> =========================================================== _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc This message may contain confidential information and is intended for specific recipients unless explicitly noted otherwise. If you have reason to believe you are not an intended recipient of this message, please delete it and notify the sender. This message may not represent the opinion of IntercontinentalExchange, Inc. (ICE), its subsidiaries or affiliates, and does not constitute a contract or guarantee. Unencrypted electronic mail is not secure and the recipient of this message is expected to provide safeguards from viruses and pursue alternate means of communication where privacy or a binding message is desired. _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc --------- Diese E-Mail könnte vertrauliche und/oder rechtlich geschützte Informationen enthalten. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail sind nicht gestattet. This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorised copying, disclosure or distribution of the material in this e-mail is strictly forbidden. ---------- _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
|
|
In reply to this post by Terry Raymond
Isn't it better to maintain the recent versioning and using (extending the implementation) a filter on blessing levels (f.e. at the right side of the PublishedItems-Tool)?
I think, it is good idea to change the blessing level after the package passes the tests. Ulli
|
Re: [vwnc] Branches as objects (was: Store - reset version number)
|
|
In reply to this post by Thorsten.Seitz-2
Yes, I very much like the idea of branches as objects in
their own right. This parallels some of the ideas that we have had
internally. But actually implementing them has taken a back seat to some
of the more urgent things that needed doing. We hope that the changes to
use Glorp for the database back-end will make it easier to do some of
these more ambitious tasks.
At 09:25 AM 2009-11-05, [hidden email] wrote: I think the problem of wanting to reset version numbers arises from a --
Alan Knight [|], Engineering Manager, Cincom Smalltalk
_______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: [vwnc] Branches as objects (was: Store - reset version number)
|
|
In reply to this post by Thorsten.Seitz-2
Thorsten said:
>> I think the problem of wanting to reset version numbers arises from a >> deficiency in Store which does not allow to distinguish between revision >> numbers (which should be fixed) and branch/release labels (which should >> be changeable -- at least until the branch gets closed, which would be >> another new concept). Currently we mix up revision numbers and branch/release >> labels within the single version number Store offers. Thorsten points to the heart of the matter; however, the remedy is far easier than many realize... The inability to distinguish between revision numbers and branch/release labels is not a Store problem but a version number problem. The common #.#.#.# numbering system breaks down over time in real-world scenarios. With two minor changes, the common numbering system (like 7.6.3.12) can accommodate branchs and revisions without confusing the two. <releaseName>.<integrationNumber>.<developerRevision> 7.6.3.12 <releaseName> <integrationNumber>.<developerRevision> 7.6 003.12 1) The traditional #.#.#.# numbering system blurs the distinction between a release name and integration. The integration number needs to be separated from the release name with something other than a period. I use a space. I also left-zero-fill the integration number to three digits so that alphanumeric sorting of build artifacts works too. When you have the separator then you can create a 7.6.1 without confusing it with 7.6 integration build 1. 2) All integration builds should be created with ".0" on the end. Release tools can do this easily. The ".0" is for the developer revision. The ".0" implies a version that other developers can load and base their changes on. Developers can publish integration-ready using whatever default number that VW assigns to the new version (.1, .2, .3 or .1, .1.1, .1.1.1). The "7.6 003.12" indicates that one developer published 12 revisions to build number 7.6 003.0. The next integration build created would be called "7.6 004.0". Other developers base their changes on 7.6 003.0 until someone (anyone) creates the next ".0" integration build. Those are the basics; now to branches... <releaseName> <integrationNumber>.<developerRevision> [branchName] <branchVersion>.<developerRevision> The "7.6.1" is a formal release name revision; it can be a revision path, but often you also want informal/temporary branches. Informal branches can be created for multiple purposes. The informal branch name has [] around it to make it easier to parse by any tools that would be made branch-aware. This is an example version that indicates a tuning effort that has been through five integrations and is based on 7.6 003.0: 7.6 003.0 [Tuning] 05.0 Now the latest 7.6 integration build is called "7.6 015.0". The changes between 7.6 003.0 and 7.6 015.0 can be merged with the Tuning work and published as "7.6 015.0 [Tuning] 05.0". Note how the branch had a separate number series that would never be confused with an other branch. Note how easy it is to know where the branch was forked from, and the fork can be shifted to different points of the main branch. You see, two minor changes to the numbering system can make it easy to accommodate many real-world dynamics. I've been using this system for many years now. It has simply eliminated many types of merge and branch problems that had been common using the #.#.#.# numbering system. Store itself isn't really deficient, but the numbering system that is commonly used with Store is. The proposed ENVY-like open editions, and/or version renaming are both techniques to work around problems with the common #.#.#.# numbering system. The simplest solution is to use a numbering system that can accommodate the kinds of real-world changes that code evolves through. Paul Baumann -----Original Message----- From: [hidden email] [mailto:[hidden email]] Sent: Thursday, November 05, 2009 9:26 AM To: Paul Baumann Cc: 'Terry Raymond'; VWNC Subject: [vwnc] Branches as objects (was: Store - reset version number) Importance: High I think the problem of wanting to reset version numbers arises from a deficiency in Store which does not allow to distinguish between revision numbers (which should be fixed) and branch/release labels (which should be changeable -- at least until the branch gets closed, which would be another new concept). Currently we mix up revision numbers and branch/release labels within the single version number Store offers. To take Terry's example, the versions 7.6.3.0, 7.6.3.1, ... 7.6.3.12 all belong to the branch intended for developing 7.6.4, so why not extract that into its own abstraction with the name "7.6.4" and with its own blessing level to indicate its status? The versions formerly called 7.6.3.0, 7.6.3.1, ... would just be the revisions 0,1 ... of that branch. I would like to see Store support this by extracting the notion of branch into an object. The branch would have a fixed branch number, a label which can be changed and it would contain revisions which are just numbered within the branch starting at 0. A revision would be identified by <branch number>.<revision number within that branch>. Prerequisites would use number>this version number to reference special versions or ranges of versions (it might make sense to allow branch labels as well -- especially if branch names become fixed when the branch gets closed). Then you would just start a new branch and add revisions to that branch. The branch would have the label 7.6.4. When it passes the tests you would change the blessing level of the *branch* to indicate that. In case of deciding that 7.6.4 should be skipped because marketing decided to release 8.0 instead :-), you would just relabel your branch to 8.0 (this works the other way around, too: say after releasing 7.6.3 you started work on 8.0 and then have to deliver the current development state as patch 7.6.4, then you might just relabel the branch, test it, close it with a blessing level to Released and start a new branch for 8.0). Having branch objects would make other things possible: for example you could display a graph where the nodes represent branches which would be much clearer than the graph of all versions. Selecting a branch would display a list of the revisions it contains besides the graph. Being able to close branch objects would make it explicit when a branch has been finished either by a release, by a dead end or by a final integration into another branch. The latter case currently cannot be distinguished from integrating the current state of the branch. Dead branches currently cannot be marked except by setting the blessing level of each version belonging to the dead branch. Just an idea. Best regards Thorsten Thorsten Seitz Development Center BahnNet I (T.SID 31) DB Systel GmbH Raum 5C.124, Alfred-Herrhausen-Allee 1, 65760 Eschborn Tel. 069/265-48245, intern 955- _________________________________________________________________________________ Internetauftritt der Deutschen Bahn AG >> http://www.db.de Sitz der Gesellschaft: Frankfurt am Main Registergericht: Frankfurt am Main, HRB 78707 USt-IdNr.: DE252204770 Geschäftsführer: Detlef Exner (Vorsitzender), Norbert Becker, Dr. Burkhard Klanke, Dr. Klaus Rüffler Vorsitzender des Aufsichtsrates: Dr. Rolf Kranüchel |-------------------------------------> | Paul Baumann | | <[hidden email]>| | Gesendet von: | | [hidden email] | | | | | | 03.11.2009 23:12 | |-------------------------------------> >-------------------------------------------------------------------------------------------------------------------------------| | | | | | An| | "'Terry Raymond'" <[hidden email]>, VWNC <[hidden email]> | | Kopie| | | | Thema| | Re: [vwnc] Store - reset version number | | | | | | | | | | | >-------------------------------------------------------------------------------------------------------------------------------| Every time this version rename discussion comes up it is followed by the late realization that "oh yeah, other users of our shared code repository already loaded versions that had been renamed; how does their trace version get fixed?". Developers don't know the (now renamed) version they'd based their changes on. When they reconcile to the wrong version (because their loaded version had been renamed) and review their changes before publishing there is some chance they'll mix up changes and mistakenly reverse changes made and integrated by others. Whoops. A version rename is safe in some situations that may apply to you. There is never a need to change a version number when you use a good numbering system and release tools. Paul Baumann -----Original Message----- From: [hidden email] [mailto:[hidden email]] On Behalf Of Terry Raymond Sent: Monday, November 02, 2009 7:21 PM To: VWNC Subject: [vwnc] Store - reset version number Hi With a store version browser one can select a version and reset the blessing level. Is there any way to select a version and change its version number? My reason for this is that one would like configuration packages to have version numbers that track releases. However, one may want to only bump a version level if at first it passes a set of tests. But, you need to assign it a version number to simply produce a frozen configuration. As it stands now you would have to load and republish just to bump the version level. By bumping the version level I mean; you start with 7.6.3.12 and if it passes the tests it becomes 7.6.4. Terry =========================================================== Terry Raymond Crafted Smalltalk 80 Lazywood Ln. Tiverton, RI 02878 (401) 624-4517 [hidden email] <http://www.craftedsmalltalk.com> =========================================================== _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc This message may contain confidential information and is intended for specific recipients unless explicitly noted otherwise. If you have reason to believe you are not an intended recipient of this message, please delete it and notify the sender. This message may not represent the opinion of IntercontinentalExchange, Inc. (ICE), its subsidiaries or affiliates, and does not constitute a contract or guarantee. Unencrypted electronic mail is not secure and the recipient of this message is expected to provide safeguards from viruses and pursue alternate means of communication where privacy or a binding message is desired. _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc --------- Diese E-Mail könnte vertrauliche und/oder rechtlich geschützte Informationen enthalten. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail sind nicht gestattet. This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorised copying, disclosure or distribution of the material in this e-mail is strictly forbidden. ---------- This message may contain confidential information and is intended for specific recipients unless explicitly noted otherwise. If you have reason to believe you are not an intended recipient of this message, please delete it and notify the sender. This message may not represent the opinion of IntercontinentalExchange, Inc. (ICE), its subsidiaries or affiliates, and does not constitute a contract or guarantee. Unencrypted electronic mail is not secure and the recipient of this message is expected to provide safeguards from viruses and pursue alternate means of communication where privacy or a binding message is desired. _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
«
Return to VisualWorks
|
1 view|%1 views
| Free forum by Nabble | Edit this page |