Enforcing vendor distribution versions

Packages that are built based on vendor parcels carry around their version  
i.e. "7.4" which is different from the package's StORE version string. We  
publish many of VW packages to our StORE repository and do maintain the  
same repository as we go through vendor releases.

A nice thing to have would be to have some sort of enforcement that a  
particular image should at least warn of packages that do not match the  
"VW distribution version" e.g. a 7.4 image should at least warn the user  
that he/she is loading a vendor package whose "VW distribution version"  
does not match "7.4" i.e. the current image distribution version.

For one this would make a little smoother to port to new VW releases.

--
Charles A. Monteiro

You could use a pre-read action on a package to test the version of the host
image where the package is being loaded

[(ObjectMemory versionId at: 5) >= 74]

Hope this helps,

-Boris

--
+1.604.689.0322
DeepCove Labs Ltd.
4th floor 595 Howe Street
Vancouver, Canada V6C 2T5

[hidden email]

CONFIDENTIALITY NOTICE

This email is intended only for the persons named in the message
header. Unless otherwise indicated, it contains information that is
private and confidential. If you have received it in error, please
notify the sender and delete the entire message including any
attachments.

Thank you.

-----Original Message-----
From: Charles A. Monteiro [mailto:[hidden email]]
Sent: Friday, March 17, 2006 11:01 AM
To: [hidden email]
Subject: Enforcing vendor distribution versions

Packages that are built based on vendor parcels carry around their version  
i.e. "7.4" which is different from the package's StORE version string. We  
publish many of VW packages to our StORE repository and do maintain the  
same repository as we go through vendor releases.

A nice thing to have would be to have some sort of enforcement that a  
particular image should at least warn of packages that do not match the  
"VW distribution version" e.g. a 7.4 image should at least warn the user  
that he/she is loading a vendor package whose "VW distribution version"  
does not match "7.4" i.e. the current image distribution version.

For one this would make a little smoother to port to new VW releases.

--
Charles A. Monteiro

well, what I want is something that would be internalized into StORE  
because I think it is generally useful. I also don't want to write  
pre-reads for vendor packages . I guess I could modify "publishing" so  
that it auto tags packages with the image versionId with the appropriate  
exception scenario handled and then enforce based on that.

Not something that I should be writing , though :), another one for the  
wish list.


-Charles


On Fri, 17 Mar 2006 14:06:14 -0500, Boris Popov <[hidden email]>  
wrote:



--
Charles A. Monteiro

No, I see your point very well, just trying to be reasonable, because
realistically the chance of this being addressed is very small at the
moment, unless the StORE team has ran out of work recently :)

-Boris

--
+1.604.689.0322
DeepCove Labs Ltd.
4th floor 595 Howe Street
Vancouver, Canada V6C 2T5

[hidden email]

CONFIDENTIALITY NOTICE

This email is intended only for the persons named in the message
header. Unless otherwise indicated, it contains information that is
private and confidential. If you have received it in error, please
notify the sender and delete the entire message including any
attachments.

Thank you.

-----Original Message-----
From: Charles A. Monteiro [mailto:[hidden email]]
Sent: Friday, March 17, 2006 11:26 AM
To: Boris Popov; [hidden email]
Subject: Re: Enforcing vendor distribution versions

well, what I want is something that would be internalized into StORE  
because I think it is generally useful. I also don't want to write  
pre-reads for vendor packages . I guess I could modify "publishing" so  
that it auto tags packages with the image versionId with the appropriate  
exception scenario handled and then enforce based on that.

Not something that I should be writing , though :), another one for the  
wish list.


-Charles


On Fri, 17 Mar 2006 14:06:14 -0500, Boris Popov <[hidden email]>  
wrote:


--
Charles A. Monteiro

The Smalltalk Industry Council Announces the Second Annual Smalltalk Solutions Coding

Competition

March 16, 2006 - The Smalltalk Industry Council (STIC) is pleased to announce the

second annual Smalltalk Solutions Smalltalk Coding Competition.  The Smalltalk

Solutions Technical Conference being held in Toronto will serve as the home for the

coding competition finale. Smalltalk Solutions is the premier forum for bringing

together Smalltalk users, developers, vendors, and enthusiasts. 

Coding contest prizes include:

1st Place ? iPod Video

2nd Place ? iPod Nano

3rd Place ? iPod Shuffle

Each of the finalists will also receive an individual membership to the STIC. 

The Smalltalk Solutions Coding Competition is broken into two phases of competition.

The first phase begins on Friday, April7th at 9:00 am EST and ends on Sunday, April

9th at midnight EST.  Registration is open and all participants must register for the

competition by sending an email to Michael Lucas-Smith at

[hidden email] by April 6, 2006.  All coding must be

done in Smalltalk, any dialect of Smalltalk.  

The Second and final phase of the competition will take place the evening of Tuesday,

April onsite at the Metro Toronto Convention Centre, home of LinuxWorld and Network

World ? Smalltalk Solutions 2006.  

Prize winners will be announced during the trade show on Wednesday, April 26, 2006.  

Contact:

Suzanne Fortman

Smalltalk Industry Council

[hidden email]

Or 

Michael Lucas-Smith

Software with Style

[hidden email]

1st Place ? iPod Video

2nd Place ? iPod Nano

3rd Place ? iPod Shuffle

Each of the finalists will also receive an individual membership to the STIC. 

The Smalltalk Solutions Coding Competition is broken into two phases of competition.

The first phase begins on Friday, April7th at 9:00 am EST and ends on Sunday, April

9th at midnight EST.  Registration is open and all participants must register for the

competition by sending an email to Michael Lucas-Smith at

[hidden email] by April 6, 2006.  All coding must be

done in Smalltalk, any dialect of Smalltalk.  

The Second and final phase of the competition will take place the evening of Tuesday,

April onsite at the Metro Toronto Convention Centre, home of LinuxWorld and Network

World ? Smalltalk Solutions 2006.  

Prize winners will be announced during the trade show on Wednesday, April 26, 2006.  

Contact:

Suzanne Fortman

Smalltalk Industry Council

[hidden email]

Or 

Michael Lucas-Smith

Software with Style

[hidden email]

Have you looked at package ExportDatabase in the Public Store
database? "This package (…) provides an export to/import from files
capability for Store, similar to what ENVY has with it's .dat files."
If you goal is to get the bundles and packages copied over to your
local database without modifications, this might be worth a try.

Runar Jordahl

No, that is not actually the goal. The goal or need/want is to have  
component versions and their dependencies remain true regardless of  
whether they exist in the context of StORE i.e. as persisted packages or  
as parcels on disk. More concretely if I persist vendor parcel A version  
7.4 into StORE it should know that it requires the specific version of  
vendor Parcel B version 7.4 regardless of what had been previously  
persisted into StORE. The "truth" is that component A requires component  
B, not any component of type B but a specific component. A component which  
I define as a specific "snapshot" of functionality ( code version)  
requires (if it does) a specific snapshot of the "other" functionality.  
Where the component lives is irrelevant.

Perhaps I need to be clearer:

One could actually manually enforce this with StORE already given certain  
conditions. For example. OracleThapiEXDI 7.4 component requires OracleEXDI  
7.4. One can persist OracleThapiEXDI 7.4 component into StORE and manually  
tag it with a version i.e. perhaps 7.4 and do the same for OracleEXDI 7.4  
component and tag it also with 7.4. Also make sure to establish the  
version pre-requisite i.e. in StORE tell the OracleThapiEXDI 7.4 package  
that it requires the OracleEXDI 7.4 package.

The thing is that OracleThapiEXDI 7.4 component already at least by human  
intention knows that it requires the 7.4 version of OracleEXDI so my point  
is that I should not have to do any of the above.

Am i whinning? maybe.

ACCESS TO A SPECIFIC OFFICIAL DISTRIBUTION REPOSITORY

What about providing access to a specific repository that houses the  
latest "stable" and officially supported versions of Cincom components .  
Perhaps this is already available. I have a script that allows me to  
simply load the latest of a set of named pundles. I actually use this to  
load my favorite IDE goodies of the public repository but would of course  
hesitate to grab the latest Cincom components from there. Don't other  
communities do this?

-Charles





On Sat, 18 Mar 2006 05:40:38 -0500, Runar Jordahl  
<[hidden email]> wrote:

> Have you looked at package ExportDatabase in the Public Store
> database? "This package (…) provides an export to/import from files
> capability for Store, similar to what ENVY has with it's .dat files."
> If you goal is to get the bundles and packages copied over to your
> local database without modifications, this might be worth a try.
>
> Runar Jordahl



--
Charles A. Monteiro

Since the thread is not dead yet :):

The requirements apply also to packages/parcels/whatever
(=pundle), not delivered by Cincom.
At the moment we have some packages in our Store repository,
which depend on the VMs/images version it is loaded into. These
are mainly fixes and addons to code not developed by us.
(Sidenote: we do not duplicate base packages in our Store
repository)

We currently use the version tag of the pundle to identify
a version suitable for the current images environment, which
is a combination of product version, image/vm version and
rarely platform. In the case of an image/vm dependent pundle,
we have a hack in place to identify a certain pattern, whereas
usually we use the version string to to identify the product
version.

It would be much nicer, if the pundles had individual
identifiers for the three mentioned dimensions (or even a generic
approach to this). This would eliminate the need for a lot of
hacks in our automated build process, which could be stripped of
some of its complexity in determining the correct version of a
pundle to load.

  Jan