Smalltalk › Cincom › VisualWorks

VisualWorks 7.7 and Prerequisites on Bundles

‹ Previous Topic Next Topic ›
 
classic Classic list List threaded Threaded
♦
♦
 8 messages Options
Runar Jordahl
Reply | Threaded
Open this post in threaded view
♦
♦
|

VisualWorks 7.7 and Prerequisites on Bundles

Runar Jordahl
If I use bundles which always have “individual functional“ packages,
why should I still have the option to specify prerequisites on the
bundle? Shouldn’t the option for specifying prerequisites on the
bundle be disabled, as the packages need to specify the prerequisites
if they really are “individual functional“?

I guess I could just ignore setting prerequisites on the bundle, and
simply verify prerequisites on packages only. Another alternative is
to maintain prerequisites on both package and bundle level, but this
creates double work. What do you recommend doing?

Kind regards
Runar

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Travis Griggs-3
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: VisualWorks 7.7 and Prerequisites on Bundles

Travis Griggs-3
On Apr 6, 2010, at 5:02 AM, Runar Jordahl wrote:

> If I use bundles which always have “individual functional“ packages,
> why should I still have the option to specify prerequisites on the
> bundle? Shouldn’t the option for specifying prerequisites on the
> bundle be disabled, as the packages need to specify the prerequisites
> if they really are “individual functional“?
>
> I guess I could just ignore setting prerequisites on the bundle, and
> simply verify prerequisites on packages only. Another alternative is
> to maintain prerequisites on both package and bundle level, but this
> creates double work. What do you recommend doing?

I would do the first. Your bundle becomes a useful way of loading a  
bunch of packages, but the packages ability to get what they need into  
the system is encapsulated to the package and not dependent on the  
bundle.

--
Travis Griggs
[hidden email]
"The dissenter is every human being at those moments of his life when  
he resigns momentarily from the herd and thinks for himself." -
Archibald MacLeish, poet and librarian




_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
davidbuck
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: VisualWorks 7.7 and Prerequisites on Bundles

davidbuck
Travis Griggs wrote: 
On Apr 6, 2010, at 5:02 AM, Runar Jordahl wrote:

  
If I use bundles which always have “individual functional“ packages,
why should I still have the option to specify prerequisites on the
bundle? Shouldn’t the option for specifying prerequisites on the
bundle be disabled, as the packages need to specify the prerequisites
if they really are “individual functional“?

I guess I could just ignore setting prerequisites on the bundle, and
simply verify prerequisites on packages only. Another alternative is
to maintain prerequisites on both package and bundle level, but this
creates double work. What do you recommend doing?
    

I would do the first. Your bundle becomes a useful way of loading a  
bunch of packages, but the packages ability to get what they need into  
the system is encapsulated to the package and not dependent on the  
bundle.
The problem with package prerequisites is that it's hard to keep track of the version numbers of the prerequisites. When you don't track version numbers, Store will either ask you which version to load or load the latest development version depending on how you have your settings set.  Neither answer allows you to recreate your system as it existed at a certain point in the past.  You can't ask Store to load the version of the code that you put into production three months ago.  It won't have the information.

I would use package prerequisites without version numbers and with the "prompt" option turned on in Store, then use bundle prerequisites to determine the actual versions to use.  This way, you get the advantages of bundle version numbers for loading and the protection of package prerequisites to tell you when you screwed up and have your bundles out of order.  Keep in mind that if your bundles are out of order in a bad way you won't be able to load them.  At least Store warns you about that these days.

Thoughts?
David Buck


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Alan Knight-2
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: VisualWorks 7.7 and Prerequisites on Bundles

Alan Knight-2
At 11:32 AM 2010-04-06, David Buck wrote:
Travis Griggs wrote: 

On Apr 6, 2010, at 5:02 AM, Runar Jordahl wrote:

 


If I use bundles which always have “individual functional“
packages,
why should I still have the option to specify prerequisites on the
bundle? Shouldn’t the option for specifying prerequisites on the
bundle be disabled, as the packages need to specify the prerequisites
if they really are “individual functional“?

I guess I could just ignore setting prerequisites on the bundle, and
simply verify prerequisites on packages only. Another alternative is
to maintain prerequisites on both package and bundle level, but this
creates double work. What do you recommend doing?
   


I would do the first. Your bundle becomes a useful way of loading a  
bunch of packages, but the packages ability to get what they need
into  
the system is encapsulated to the package and not dependent on the  
bundle.
 
The problem with package prerequisites is that it's hard to keep track of the version numbers of the prerequisites. When you don't track version numbers, Store will either ask you which version to load or load the latest development version depending on how you have your settings set.  Neither answer allows you to recreate your system as it existed at a certain point in the past.  You can't ask Store to load the version of the code that you put into production three months ago.  It won't have the information.

I would use package prerequisites without version numbers and with the "prompt" option turned on in Store, then use bundle prerequisites to determine the actual versions to use.  This way, you get the advantages of bundle version numbers for loading and the protection of package prerequisites to tell you when you screwed up and have your bundles out of order.  Keep in mind that if your bundles are out of order in a bad way you won't be able to load them.  At least Store warns you about that these days.

Thoughts?
David Buck

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

--
Alan Knight [|], Engineering Manager, Cincom Smalltalk

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Alan Knight-2
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: VisualWorks 7.7 and Prerequisites on Bundles

Alan Knight-2
In reply to this post by davidbuck
At 11:32 AM 2010-04-06, David Buck wrote:
Travis Griggs wrote: 

On Apr 6, 2010, at 5:02 AM, Runar Jordahl wrote:

 


If I use bundles which always have “individual functional“
packages,
why should I still have the option to specify prerequisites on the
bundle? Shouldn’t the option for specifying prerequisites on the
bundle be disabled, as the packages need to specify the prerequisites
if they really are “individual functional“?

I guess I could just ignore setting prerequisites on the bundle, and
simply verify prerequisites on packages only. Another alternative is
to maintain prerequisites on both package and bundle level, but this
creates double work. What do you recommend doing?
   


I would do the first. Your bundle becomes a useful way of loading a  
bunch of packages, but the packages ability to get what they need
into  
the system is encapsulated to the package and not dependent on the  
bundle.
 
The problem with package prerequisites is that it's hard to keep track of the version numbers of the prerequisites. When you don't track version numbers, Store will either ask you which version to load or load the latest development version depending on how you have your settings set.  Neither answer allows you to recreate your system as it existed at a certain point in the past.  You can't ask Store to load the version of the code that you put into production three months ago.  It won't have the information.

I would use package prerequisites without version numbers and with the "prompt" option turned on in Store, then use bundle prerequisites to determine the actual versions to use.  This way, you get the advantages of bundle version numbers for loading and the protection of package prerequisites to tell you when you screwed up and have your bundles out of order.  Keep in mind that if your bundles are out of order in a bad way you won't be able to load them.  At least Store warns you about that these days.

Thoughts?

Well, the alternative is not to keep track of the complete contents of a build by using prerequisites. What we do for our internal builds is keep track of it externally (in cryptic text files right now, although we're looking at improving those mechanisms).  If you use versioned prerequisites, then you end up needing to edit them frequently, even if the thing in question hasn't changed, because somewhere down the chain of prerequisites, something has. It would be nice if Store had a mechanism for keeping track of such larger scale configurations, and we have longer-term plans to do so, but in the meantime, I'm not sure prerequisites is the best way to accomplish that.


--
Alan Knight [|], Engineering Manager, Cincom Smalltalk

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Terry Raymond
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: VisualWorks 7.7 and Prerequisites on Bundles

Terry Raymond

Another alternative is not to use bundles but to use a configuration

package that specifies all the prerequisites. You set the system

Prerequisites setting to load the latest version with a blessing of

what you like, I use Development. When you create a released

system you create and publish a special copy of this configuration

package so the prerequisite list now specifies the loaded versions.

 

Because the Prerequisite setting is actually a policy you could create

a rule based policy that could also specify what the version number

pattern looks like so forks would not get loaded. This gets us a little

closer to the configuration capabilities that Envy has.

 

Look at the “Store Lineup Extensions” in the public repository.

 

Terry

===========================================================
Terry Raymond
Crafted Smalltalk
80 Lazywood Ln.
Tiverton, RI  02878
(401) 624-4517      [hidden email]
<http://www.craftedsmalltalk.com>
===========================================================

From: [hidden email] [mailto:[hidden email]] On Behalf Of Alan Knight
Sent: Tuesday, April 06, 2010 1:18 PM
To: David Buck; VWNC NC
Subject: Re: [vwnc] VisualWorks 7.7 and Prerequisites on Bundles

 

At 11:32 AM 2010-04-06, David Buck wrote:

Travis Griggs wrote:

 

On Apr 6, 2010, at 5:02 AM, Runar Jordahl wrote:
 
 

 

If I use bundles which always have “individual functional“
packages,
why should I still have the option to specify prerequisites on the
bundle? Shouldn’t the option for specifying prerequisites on the
bundle be disabled, as the packages need to specify the prerequisites
if they really are “individual functional“?
 
I guess I could just ignore setting prerequisites on the bundle, and
simply verify prerequisites on packages only. Another alternative is
to maintain prerequisites on both package and bundle level, but this
creates double work. What do you recommend doing?
   

 

 
I would do the first. Your bundle becomes a useful way of loading a  
bunch of packages, but the packages ability to get what they need
into  
the system is encapsulated to the package and not dependent on the  
bundle.
 

The problem with package prerequisites is that it's hard to keep track of the version numbers of the prerequisites. When you don't track version numbers, Store will either ask you which version to load or load the latest development version depending on how you have your settings set.  Neither answer allows you to recreate your system as it existed at a certain point in the past.  You can't ask Store to load the version of the code that you put into production three months ago.  It won't have the information.

I would use package prerequisites without version numbers and with the "prompt" option turned on in Store, then use bundle prerequisites to determine the actual versions to use.  This way, you get the advantages of bundle version numbers for loading and the protection of package prerequisites to tell you when you screwed up and have your bundles out of order.  Keep in mind that if your bundles are out of order in a bad way you won't be able to load them.  At least Store warns you about that these days.

Thoughts?


Well, the alternative is not to keep track of the complete contents of a build by using prerequisites. What we do for our internal builds is keep track of it externally (in cryptic text files right now, although we're looking at improving those mechanisms).  If you use versioned prerequisites, then you end up needing to edit them frequently, even if the thing in question hasn't changed, because somewhere down the chain of prerequisites, something has. It would be nice if Store had a mechanism for keeping track of such larger scale configurations, and we have longer-term plans to do so, but in the meantime, I'm not sure prerequisites is the best way to accomplish that.

 

--

Alan Knight [|], Engineering Manager, Cincom Smalltalk


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Randy Coulman
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: VisualWorks 7.7 and Prerequisites on Bundles

Randy Coulman


On Tue, Apr 6, 2010 at 10:59 AM, Terry Raymond <[hidden email]> wrote:

Because the Prerequisite setting is actually a policy you could create

a rule based policy that could also specify what the version number

pattern looks like so forks would not get loaded. This gets us a little

closer to the configuration capabilities that Envy has.

 

Look at the “Store Lineup Extensions” in the public repository.

And see StoreRegexPrerequisitePolicy for a policy that uses regular expressions to specify such a pattern.

Randy
--
Randy Coulman
[hidden email]

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Holger Kleinsorgen-4
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: VisualWorks 7.7 and Prerequisites on Bundles

Holger Kleinsorgen-4
In reply to this post by Terry Raymond
Am 06.04.2010 19:59, schrieb Terry Raymond:

>
> Another alternative is not to use bundles but to use a configuration
>
> package that specifies all the prerequisites. You set the system
>
> Prerequisites setting to load the latest version with a blessing of
>
> what you like, I use Development. When you create a released
>
> system you create and publish a special copy of this configuration
>
> package so the prerequisite list now specifies the loaded versions.
>
> Because the Prerequisite setting is actually a policy you could create
>
> a rule based policy that could also specify what the version number
>
> pattern looks like so forks would not get loaded. This gets us a little
>
> closer to the configuration capabilities that Envy has.
>
>

at our shop we use package prerequisites (without version),
configuration maps (with regular version expressions), and bundles
the basic roles are

1. a configuration map determines which pundles and which versions to load
2. the package prerequisites determine the load order. this is  
important, because for deployments we only deploy packages
3. the bundles organize the packages visually. they also help when
publishing a larger number of packages within a bundle.

bundles are usually used as somemething similar to "open editions"
(talking in EnVY slang). when the software is released, bundles are
published with release blessings, so we could reconstruct the image from
the bundles (but it's easier to keep a development image somewhere safe).


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Free forum by Nabble Edit this page