[Best practices?] Build number in packaged image

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

[Best practices?] Build number in packaged image

jtuchel
Hi,

Do others include some string into their packaged images to indicate the build number or - even better - the version name of some config map or such? How do they do that? 
Almost everything that I can think of has drawbacks, most of them being that some user has to actively do something that ends up in a newly compiled method (whereby the version number of a config map wouldn't be accurate any more unless you first version that stuff and package afterwards...).

Are there any best practices how to do that fully automatically in the packaging process? Where do you keep these numbers/strings? How do you update them?

Just wondering because this would be handy in some situations. Mostly ones that are unpleasant (like users reporting urgent errors friday nights).

Joachim

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To view this discussion on the web visit https://groups.google.com/d/msg/va-smalltalk/-/l1oai8pChQsJ.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/va-smalltalk?hl=en.
Reply | Threaded
Open this post in threaded view
|

Re: [Best practices?] Build number in packaged image

Randy Nelson-2
My favorite solution was to put "Smalltalk at: #TheApplicationVersionString put: '1.2.7.0 v0' .false" in the base config map "Config. Expressions" field...followed by a "true" line. Then whenever a new map was opened, the version was updated and anyone loading the map would automatically get the correct version. (including the builder). BTW, the "true" line would have the associated required maps, (if any)...

Hope that helps

On Wed, Nov 28, 2012 at 3:24 PM, [hidden email] <[hidden email]> wrote:
Hi,

Do others include some string into their packaged images to indicate the build number or - even better - the version name of some config map or such? How do they do that? 
Almost everything that I can think of has drawbacks, most of them being that some user has to actively do something that ends up in a newly compiled method (whereby the version number of a config map wouldn't be accurate any more unless you first version that stuff and package afterwards...).

Are there any best practices how to do that fully automatically in the packaging process? Where do you keep these numbers/strings? How do you update them?

Just wondering because this would be handy in some situations. Mostly ones that are unpleasant (like users reporting urgent errors friday nights).

Joachim

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To view this discussion on the web visit https://groups.google.com/d/msg/va-smalltalk/-/l1oai8pChQsJ.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/va-smalltalk?hl=en.

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/va-smalltalk?hl=en.
Reply | Threaded
Open this post in threaded view
|

Re: [Best practices?] Build number in packaged image

SebastianHC
In reply to this post by jtuchel
I usually take the inheritedUserField

Sebastian


Am 28.11.2012 12:24, schrieb [hidden email]:

> Hi,
>
> Do others include some string into their packaged images to indicate
> the build number or - even better - the version name of some config
> map or such? How do they do that?
> Almost everything that I can think of has drawbacks, most of them
> being that some user has to actively do something that ends up in a
> newly compiled method (whereby the version number of a config map
> wouldn't be accurate any more unless you first version that stuff and
> package afterwards...).
>
> Are there any best practices how to do that fully automatically in the
> packaging process? Where do you keep these numbers/strings? How do you
> update them?
>
> Just wondering because this would be handy in some situations. Mostly
> ones that are unpleasant (like users reporting urgent errors friday
> nights).
>
> Joachim
> --
> You received this message because you are subscribed to the Google
> Groups "VA Smalltalk" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/va-smalltalk/-/l1oai8pChQsJ.
> To post to this group, send email to [hidden email].
> To unsubscribe from this group, send email to
> [hidden email].
> For more options, visit this group at
> http://groups.google.com/group/va-smalltalk?hl=en.

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/va-smalltalk?hl=en.

Reply | Threaded
Open this post in threaded view
|

Re: [Best practices?] Build number in packaged image

jtuchel
but that is not under version control, right?

Am Mittwoch, 28. November 2012 21:39:06 UTC+1 schrieb Sebastian Heidbrink:
I usually take the inheritedUserField

Sebastian


Am 28.11.2012 12:24, schrieb <a href="javascript:" target="_blank" gdf-obfuscated-mailto="H_ksgrSVW1sJ">jtu...@...:

> Hi,
>
> Do others include some string into their packaged images to indicate
> the build number or - even better - the version name of some config
> map or such? How do they do that?
> Almost everything that I can think of has drawbacks, most of them
> being that some user has to actively do something that ends up in a
> newly compiled method (whereby the version number of a config map
> wouldn't be accurate any more unless you first version that stuff and
> package afterwards...).
>
> Are there any best practices how to do that fully automatically in the
> packaging process? Where do you keep these numbers/strings? How do you
> update them?
>
> Just wondering because this would be handy in some situations. Mostly
> ones that are unpleasant (like users reporting urgent errors friday
> nights).
>
> Joachim
> --
> You received this message because you are subscribed to the Google
> Groups "VA Smalltalk" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/va-smalltalk/-/l1oai8pChQsJ.
> To post to this group, send email to <a href="javascript:" target="_blank" gdf-obfuscated-mailto="H_ksgrSVW1sJ">va-sma...@....
> To unsubscribe from this group, send email to
> <a href="javascript:" target="_blank" gdf-obfuscated-mailto="H_ksgrSVW1sJ">va-smalltalk...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/va-smalltalk?hl=en.

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To view this discussion on the web visit https://groups.google.com/d/msg/va-smalltalk/-/0YXdhIVN1UgJ.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/va-smalltalk?hl=en.
Reply | Threaded
Open this post in threaded view
|

Re: [Best practices?] Build number in packaged image

SebastianHC
It should, well, in my case it is attached to a config map version,... so somehow it is ;-)

Sebastian

Am 28.11.2012 13:13, schrieb [hidden email]:
but that is not under version control, right?

Am Mittwoch, 28. November 2012 21:39:06 UTC+1 schrieb Sebastian Heidbrink:
I usually take the inheritedUserField

Sebastian


Am 28.11.2012 12:24, schrieb <a moz-do-not-send="true" href="javascript:" target="_blank" gdf-obfuscated-mailto="H_ksgrSVW1sJ">jtu...@...:
> Hi,
>
> Do others include some string into their packaged images to indicate
> the build number or - even better - the version name of some config
> map or such? How do they do that?
> Almost everything that I can think of has drawbacks, most of them
> being that some user has to actively do something that ends up in a
> newly compiled method (whereby the version number of a config map
> wouldn't be accurate any more unless you first version that stuff and
> package afterwards...).
>
> Are there any best practices how to do that fully automatically in the
> packaging process? Where do you keep these numbers/strings? How do you
> update them?
>
> Just wondering because this would be handy in some situations. Mostly
> ones that are unpleasant (like users reporting urgent errors friday
> nights).
>
> Joachim
> --
> You received this message because you are subscribed to the Google
> Groups "VA Smalltalk" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/va-smalltalk/-/l1oai8pChQsJ.
> To post to this group, send email to <a moz-do-not-send="true" href="javascript:" target="_blank" gdf-obfuscated-mailto="H_ksgrSVW1sJ">va-sma...@....
> To unsubscribe from this group, send email to
> <a moz-do-not-send="true" href="javascript:" target="_blank" gdf-obfuscated-mailto="H_ksgrSVW1sJ">va-smalltalk...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/va-smalltalk?hl=en.

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To view this discussion on the web visit https://groups.google.com/d/msg/va-smalltalk/-/0YXdhIVN1UgJ.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/va-smalltalk?hl=en.

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/va-smalltalk?hl=en.
Reply | Threaded
Open this post in threaded view
|

Re: [Best practices?] Build number in packaged image

jtuchel
In reply to this post by Randy Nelson-2
Cool. So you didn't use some Application's #loaded to put the value into the Smalltalk PoolDict, but misused the config expressions feature. Combined with a packaging rule that includes the constant in the packaged image, that would be exactly what I'm looking for.
I am not sure I fully understood it. Are you saying you used some config expression to set the number and returned false so that it was never used for loading required maps? Dirty and cool at the same time ;-?

I think I like the concept, because I could call some method that does the "heavy lifting" of automatically reading the version name of the config map's loaded edition. 
But as I understand the load order of config maps, I cannot access the edition of the map that is currently in process of loading, right? At the moment a config expression is evaluated, the edition of the map may is most likely not yet loaded, becaus envy will first have to check if it has to load required maps before that . So I'd have to either always use the latest map edition or manage that String manually, right?

So the last piece in my mosaic would be if there is a way to access the map edition from within a configuration expression and I'd buy into this idea instantly!

Thanks for sharing this idea, it sounds promising to me.

But maybe I see another alternative:

Why not use the #loaded method of some Application in the topmost map, that asks for the loaded version of my top map and does the same thing? .... hmmm. gotta think about it.

Joachim
 

Am Mittwoch, 28. November 2012 21:33:52 UTC+1 schrieb RNelson:
My favorite solution was to put "Smalltalk at: #TheApplicationVersionString put: '1.2.7.0 v0' .false" in the base config map "Config. Expressions" field...followed by a "true" line. Then whenever a new map was opened, the version was updated and anyone loading the map would automatically get the correct version. (including the builder). BTW, the "true" line would have the associated required maps, (if any)...

Hope that helps

On Wed, Nov 28, 2012 at 3:24 PM, <a href="javascript:" target="_blank" gdf-obfuscated-mailto="yy_9N936O44J">jtu...@... <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="yy_9N936O44J">jtu...@...> wrote:
Hi,

Do others include some string into their packaged images to indicate the build number or - even better - the version name of some config map or such? How do they do that? 
Almost everything that I can think of has drawbacks, most of them being that some user has to actively do something that ends up in a newly compiled method (whereby the version number of a config map wouldn't be accurate any more unless you first version that stuff and package afterwards...).

Are there any best practices how to do that fully automatically in the packaging process? Where do you keep these numbers/strings? How do you update them?

Just wondering because this would be handy in some situations. Mostly ones that are unpleasant (like users reporting urgent errors friday nights).

Joachim

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To view this discussion on the web visit https://groups.google.com/d/msg/va-smalltalk/-/l1oai8pChQsJ.
To post to this group, send email to <a href="javascript:" target="_blank" gdf-obfuscated-mailto="yy_9N936O44J">va-sma...@....
To unsubscribe from this group, send email to <a href="javascript:" target="_blank" gdf-obfuscated-mailto="yy_9N936O44J">va-smalltalk...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/va-smalltalk?hl=en.

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To view this discussion on the web visit https://groups.google.com/d/msg/va-smalltalk/-/DSIlpLDXBPkJ.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/va-smalltalk?hl=en.
Reply | Threaded
Open this post in threaded view
|

Re: [Best practices?] Build number in packaged image

jtuchel
In reply to this post by SebastianHC
hugh? Attached to a version? Not too bad. Never thought about that. So what do you put in there? A build number? how does it get incremented?

I am looking for something that can't even fail if I am in charge of packaging ;-)

Joachim

Am Mittwoch, 28. November 2012 22:23:47 UTC+1 schrieb Sebastian Heidbrink:
It should, well, in my case it is attached to a config map version,... so somehow it is ;-)

Sebastian

Am 28.11.2012 13:13, schrieb <a href="javascript:" target="_blank" gdf-obfuscated-mailto="sg0g4juQHu4J">jtu...@...:
but that is not under version control, right?

Am Mittwoch, 28. November 2012 21:39:06 UTC+1 schrieb Sebastian Heidbrink:
I usually take the inheritedUserField

Sebastian


Am 28.11.2012 12:24, schrieb [hidden email]:
> Hi,
>
> Do others include some string into their packaged images to indicate
> the build number or - even better - the version name of some config
> map or such? How do they do that?
> Almost everything that I can think of has drawbacks, most of them
> being that some user has to actively do something that ends up in a
> newly compiled method (whereby the version number of a config map
> wouldn't be accurate any more unless you first version that stuff and
> package afterwards...).
>
> Are there any best practices how to do that fully automatically in the
> packaging process? Where do you keep these numbers/strings? How do you
> update them?
>
> Just wondering because this would be handy in some situations. Mostly
> ones that are unpleasant (like users reporting urgent errors friday
> nights).
>
> Joachim
> --
> You received this message because you are subscribed to the Google
> Groups "VA Smalltalk" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/va-smalltalk/-/l1oai8pChQsJ.
> To post to this group, send email to [hidden email].
> To unsubscribe from this group, send email to
> va-smalltalk...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/va-smalltalk?hl=en.

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To view this discussion on the web visit https://groups.google.com/d/msg/va-smalltalk/-/0YXdhIVN1UgJ.
To post to this group, send email to <a href="javascript:" target="_blank" gdf-obfuscated-mailto="sg0g4juQHu4J">va-sma...@....
To unsubscribe from this group, send email to <a href="javascript:" target="_blank" gdf-obfuscated-mailto="sg0g4juQHu4J">va-smalltalk...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/va-smalltalk?hl=en.

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To view this discussion on the web visit https://groups.google.com/d/msg/va-smalltalk/-/FQk8OtiipCYJ.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/va-smalltalk?hl=en.
Reply | Threaded
Open this post in threaded view
|

Re: [Best practices?] Build number in packaged image

SebastianHC
I put the software release version number in it. Sometimes you have checkpoints or minor versions in the configmaps which do not correspond to a application version.
I extended the configuration maps browser by a menu entry which allows me to set the version number by hand. This number is then shown in the the configuration maps browser' shell title.

This is quite handy, because now you can have other VAST extensions like opening a new version of an application and telling it in which version of a map it shall be released (or better say for which software version you open an edition of an app). Or if you have a bug fix map for an older release you can make sure that nobody accidently released an already newer version of an app in your bug fix map which should not be included/packaged with the fix.

Sebastian


Am 28.11.2012 13:32, schrieb [hidden email]:
hugh? Attached to a version? Not too bad. Never thought about that. So what do you put in there? A build number? how does it get incremented?

I am looking for something that can't even fail if I am in charge of packaging ;-)

Joachim

Am Mittwoch, 28. November 2012 22:23:47 UTC+1 schrieb Sebastian Heidbrink:
It should, well, in my case it is attached to a config map version,... so somehow it is ;-)

Sebastian

Am 28.11.2012 13:13, schrieb <a moz-do-not-send="true" href="javascript:" target="_blank" gdf-obfuscated-mailto="sg0g4juQHu4J">jtu...@...:
but that is not under version control, right?

Am Mittwoch, 28. November 2012 21:39:06 UTC+1 schrieb Sebastian Heidbrink:
I usually take the inheritedUserField

Sebastian


Am 28.11.2012 12:24, schrieb [hidden email]:
> Hi,
>
> Do others include some string into their packaged images to indicate
> the build number or - even better - the version name of some config
> map or such? How do they do that?
> Almost everything that I can think of has drawbacks, most of them
> being that some user has to actively do something that ends up in a
> newly compiled method (whereby the version number of a config map
> wouldn't be accurate any more unless you first version that stuff and
> package afterwards...).
>
> Are there any best practices how to do that fully automatically in the
> packaging process? Where do you keep these numbers/strings? How do you
> update them?
>
> Just wondering because this would be handy in some situations. Mostly
> ones that are unpleasant (like users reporting urgent errors friday
> nights).
>
> Joachim
> --
> You received this message because you are subscribed to the Google
> Groups "VA Smalltalk" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/va-smalltalk/-/l1oai8pChQsJ.
> To post to this group, send email to [hidden email].
> To unsubscribe from this group, send email to
> va-smalltalk...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/va-smalltalk?hl=en.

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To view this discussion on the web visit https://groups.google.com/d/msg/va-smalltalk/-/0YXdhIVN1UgJ.
To post to this group, send email to <a moz-do-not-send="true" href="javascript:" target="_blank" gdf-obfuscated-mailto="sg0g4juQHu4J">va-sma...@....
To unsubscribe from this group, send email to <a moz-do-not-send="true" href="javascript:" target="_blank" gdf-obfuscated-mailto="sg0g4juQHu4J">va-smalltalk...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/va-smalltalk?hl=en.

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To view this discussion on the web visit https://groups.google.com/d/msg/va-smalltalk/-/FQk8OtiipCYJ.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/va-smalltalk?hl=en.

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/va-smalltalk?hl=en.
Reply | Threaded
Open this post in threaded view
|

Re: [Best practices?] Build number in packaged image

Randy Nelson-2
In reply to this post by jtuchel
I don't usually suffer from the "over-thinking it" problem...usually the opposite...  :o)  I think simply the config expressions are evaluated until one returns true and its associated required maps are loaded. So the false line just sets the version into a global using a string and continues on to the next line that loads the required maps, (and is "true"). We have it in the base map so it's guaranteed to be there, (with the pkging rule you mentioned). It was much simpler for us because we were okay with a string in the expression and didn't care to try and grab the map version it was loading or something like that...but that would be way cool if you can get that to work.

Usually I only get one of those adjectives...and it's not the "cool" one....   :o)

Hope that helps

On Wed, Nov 28, 2012 at 4:30 PM, [hidden email] <[hidden email]> wrote:
Cool. So you didn't use some Application's #loaded to put the value into the Smalltalk PoolDict, but misused the config expressions feature. Combined with a packaging rule that includes the constant in the packaged image, that would be exactly what I'm looking for.
I am not sure I fully understood it. Are you saying you used some config expression to set the number and returned false so that it was never used for loading required maps? Dirty and cool at the same time ;-?

I think I like the concept, because I could call some method that does the "heavy lifting" of automatically reading the version name of the config map's loaded edition. 
But as I understand the load order of config maps, I cannot access the edition of the map that is currently in process of loading, right? At the moment a config expression is evaluated, the edition of the map may is most likely not yet loaded, becaus envy will first have to check if it has to load required maps before that . So I'd have to either always use the latest map edition or manage that String manually, right?

So the last piece in my mosaic would be if there is a way to access the map edition from within a configuration expression and I'd buy into this idea instantly!

Thanks for sharing this idea, it sounds promising to me.

But maybe I see another alternative:

Why not use the #loaded method of some Application in the topmost map, that asks for the loaded version of my top map and does the same thing? .... hmmm. gotta think about it.

Joachim
 

Am Mittwoch, 28. November 2012 21:33:52 UTC+1 schrieb RNelson:
My favorite solution was to put "Smalltalk at: #TheApplicationVersionString put: '1.2.7.0 v0' .false" in the base config map "Config. Expressions" field...followed by a "true" line. Then whenever a new map was opened, the version was updated and anyone loading the map would automatically get the correct version. (including the builder). BTW, the "true" line would have the associated required maps, (if any)...

Hope that helps

On Wed, Nov 28, 2012 at 3:24 PM, [hidden email] <[hidden email]> wrote:
Hi,

Do others include some string into their packaged images to indicate the build number or - even better - the version name of some config map or such? How do they do that? 
Almost everything that I can think of has drawbacks, most of them being that some user has to actively do something that ends up in a newly compiled method (whereby the version number of a config map wouldn't be accurate any more unless you first version that stuff and package afterwards...).

Are there any best practices how to do that fully automatically in the packaging process? Where do you keep these numbers/strings? How do you update them?

Just wondering because this would be handy in some situations. Mostly ones that are unpleasant (like users reporting urgent errors friday nights).

Joachim

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To view this discussion on the web visit https://groups.google.com/d/msg/va-smalltalk/-/l1oai8pChQsJ.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to va-smalltalk...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/va-smalltalk?hl=en.

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To view this discussion on the web visit https://groups.google.com/d/msg/va-smalltalk/-/DSIlpLDXBPkJ.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/va-smalltalk?hl=en.

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/va-smalltalk?hl=en.
Reply | Threaded
Open this post in threaded view
|

Re: [Best practices?] Build number in packaged image

jtuchel
We represent a "stream" by a top-level map that allows for one-click loading. We also have a number of tools for releasing into a stream or diffing a stream with other streams of versions of itself. So that top-level map is the place that defines a product version (or the build's contents) best in our scenario. A base map wouldn't work for us if we'd want the top level's map version into the packaged image for the reasons I've mentioned.

But putting some application into the top level map and implementing the method string generation (whatever that may be, possibly just the number of minutes the map's version timestamp represents or such) into its #loaded method sounds promising.

In the end, this wouldn't really look much like your suggested solution, but your idea got me into the right thinking mode for mine ;-) And I thank you very much for that!

Joachim

Am Mittwoch, 28. November 2012 22:51:57 UTC+1 schrieb RNelson:
I don't usually suffer from the "over-thinking it" problem...usually the opposite...  :o)  I think simply the config expressions are evaluated until one returns true and its associated required maps are loaded. So the false line just sets the version into a global using a string and continues on to the next line that loads the required maps, (and is "true"). We have it in the base map so it's guaranteed to be there, (with the pkging rule you mentioned). It was much simpler for us because we were okay with a string in the expression and didn't care to try and grab the map version it was loading or something like that...but that would be way cool if you can get that to work.

Usually I only get one of those adjectives...and it's not the "cool" one....   :o)

Hope that helps

On Wed, Nov 28, 2012 at 4:30 PM, <a href="javascript:" target="_blank" gdf-obfuscated-mailto="e2JiSl8e_eEJ">jtu...@... <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="e2JiSl8e_eEJ">jtu...@...> wrote:
Cool. So you didn't use some Application's #loaded to put the value into the Smalltalk PoolDict, but misused the config expressions feature. Combined with a packaging rule that includes the constant in the packaged image, that would be exactly what I'm looking for.
I am not sure I fully understood it. Are you saying you used some config expression to set the number and returned false so that it was never used for loading required maps? Dirty and cool at the same time ;-?

I think I like the concept, because I could call some method that does the "heavy lifting" of automatically reading the version name of the config map's loaded edition. 
But as I understand the load order of config maps, I cannot access the edition of the map that is currently in process of loading, right? At the moment a config expression is evaluated, the edition of the map may is most likely not yet loaded, becaus envy will first have to check if it has to load required maps before that . So I'd have to either always use the latest map edition or manage that String manually, right?

So the last piece in my mosaic would be if there is a way to access the map edition from within a configuration expression and I'd buy into this idea instantly!

Thanks for sharing this idea, it sounds promising to me.

But maybe I see another alternative:

Why not use the #loaded method of some Application in the topmost map, that asks for the loaded version of my top map and does the same thing? .... hmmm. gotta think about it.

Joachim
 

Am Mittwoch, 28. November 2012 21:33:52 UTC+1 schrieb RNelson:
My favorite solution was to put "Smalltalk at: #TheApplicationVersionString put: '1.2.7.0 v0' .false" in the base config map "Config. Expressions" field...followed by a "true" line. Then whenever a new map was opened, the version was updated and anyone loading the map would automatically get the correct version. (including the builder). BTW, the "true" line would have the associated required maps, (if any)...

Hope that helps

On Wed, Nov 28, 2012 at 3:24 PM, [hidden email] <[hidden email]> wrote:
Hi,

Do others include some string into their packaged images to indicate the build number or - even better - the version name of some config map or such? How do they do that? 
Almost everything that I can think of has drawbacks, most of them being that some user has to actively do something that ends up in a newly compiled method (whereby the version number of a config map wouldn't be accurate any more unless you first version that stuff and package afterwards...).

Are there any best practices how to do that fully automatically in the packaging process? Where do you keep these numbers/strings? How do you update them?

Just wondering because this would be handy in some situations. Mostly ones that are unpleasant (like users reporting urgent errors friday nights).

Joachim

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To view this discussion on the web visit https://groups.google.com/d/msg/va-smalltalk/-/l1oai8pChQsJ.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to va-smalltalk...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/va-smalltalk?hl=en.

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To view this discussion on the web visit https://groups.google.com/d/msg/va-smalltalk/-/DSIlpLDXBPkJ.
To post to this group, send email to <a href="javascript:" target="_blank" gdf-obfuscated-mailto="e2JiSl8e_eEJ">va-sma...@....
To unsubscribe from this group, send email to <a href="javascript:" target="_blank" gdf-obfuscated-mailto="e2JiSl8e_eEJ">va-smalltalk...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/va-smalltalk?hl=en.

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To view this discussion on the web visit https://groups.google.com/d/msg/va-smalltalk/-/0FzQU7jVUFwJ.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/va-smalltalk?hl=en.
Reply | Threaded
Open this post in threaded view
|

Re: [Best practices?] Build number in packaged image

Marten Feldtmann-2
Why not add an empty application in the config map - and the version number of this application IS your application version.
To make it nicer, the developer version the config map and this empty application the same way ?

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To view this discussion on the web visit https://groups.google.com/d/msg/va-smalltalk/-/MwfBnPWUom0J.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/va-smalltalk?hl=en.
Reply | Threaded
Open this post in threaded view
|

Re: [Best practices?] Build number in packaged image

jtuchel
Good idea. I'm not yet sure whether I like that more than versioning the config map. At least the config map will have to be versioned from time to time anyways in our development process. The Application is one more item to think of and therefor a possible point of failure, while the map versioning is part of our process. The rule already is: if you package, you version the map. The rule then would be: if you package, you version the map and ths new Application. Not that both of that couldn't be automated anyways, but that's another story ;-)

In any case, I am grateful for all ideas that were mentioned here.

Joachim

Am Donnerstag, 29. November 2012 07:26:04 UTC+1 schrieb Marten Feldtmann:
Why not add an empty application in the config map - and the version number of this application IS your application version.
To make it nicer, the developer version the config map and this empty application the same way ?

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To view this discussion on the web visit https://groups.google.com/d/msg/va-smalltalk/-/E7Kp1BgiveoJ.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/va-smalltalk?hl=en.
Reply | Threaded
Open this post in threaded view
|

Re: [Best practices?] Build number in packaged image

Thomas Koschate-2
In reply to this post by jtuchel
On Wednesday, November 28, 2012 4:30:11 PM UTC-5, [hidden email] wrote:
 
Why not use the #loaded method of some Application in the topmost map, that asks for the loaded version of my top map and does the same thing? .... hmmm. gotta think about it.

You do want to be careful of what you do in a #loaded method in a headless image - these methods are executed every time the image is started, not just when the image is packaged.

Tom

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To view this discussion on the web visit https://groups.google.com/d/msg/va-smalltalk/-/FZmij4s9S1EJ.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/va-smalltalk?hl=en.
Reply | Threaded
Open this post in threaded view
|

Re: [Best practices?] Build number in packaged image

jtuchel
Hi Tom,

I wasn't aware of that, so thanks for this hint. 
So I'd exclude the #loaded from the packaged image, it's job would simply be to update a global variable to the appropriate version number as soon as code is loaded into our image, be it a development or packaging image. It has no job to do in a runtime image. It wouldn't find a Configuration Map class in there anyways (or if it would, I'd do a lousy job of Packaging).

Joachim


Am Donnerstag, 29. November 2012 13:43:45 UTC+1 schrieb Thomas Koschate:
On Wednesday, November 28, 2012 4:30:11 PM UTC-5, [hidden email] wrote:
 
Why not use the #loaded method of some Application in the topmost map, that asks for the loaded version of my top map and does the same thing? .... hmmm. gotta think about it.

You do want to be careful of what you do in a #loaded method in a headless image - these methods are executed every time the image is started, not just when the image is packaged.

Tom

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To view this discussion on the web visit https://groups.google.com/d/msg/va-smalltalk/-/3cBMicVDnTwJ.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/va-smalltalk?hl=en.
Reply | Threaded
Open this post in threaded view
|

Re: [Best practices?] Build number in packaged image

Thomas Koschate-2
On Friday, November 30, 2012 2:09:52 AM UTC-5, [hidden email] wrote:
 
I wasn't aware of that, so thanks for this hint. 
So I'd exclude the #loaded from the packaged image, it's job would simply be to update a global variable to the appropriate version number as soon as code is loaded into our image, be it a development or packaging image. It has no job to do in a runtime image. It wouldn't find a Configuration Map class in there anyways (or if it would, I'd do a lousy job of Packaging). 

Headless is a funny animal - it's also not reduced, unless you have some explicit packaging rule that deletes stuff.  Otherwise, everything loaded into the XD image is there in the final product.  Actual development tools aren't part of that, only the code you selected in the image characteristics and things that are loaded in your config maps.You wouldn't be able to successfully load UI classes, for instance.

Tom

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To view this discussion on the web visit https://groups.google.com/d/msg/va-smalltalk/-/lixExy0R83sJ.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/va-smalltalk?hl=en.