[Pharo-project] System -> About in Dev images
Hi folks: If you take a Dev image and go to " System->About " you get something like: PharoCore1.0rc1 Latest update: #10505 However, I would like to show something like this for example: Pharo1.0-10505-rc1dev10.01.1 PharoCore1.0rc1 Latest update: #10505 Do you know how we can change this? How can I set that name when building a PharoDev image? Is this related to SystemVersion ?? We need to have this fixed for the official 1.0 release. Cheers Mariano
Hi you need to set SystemVersion current type: 'Pharo' to change the core image it is built from to be Pharo. or if we abandon the distinction SystemVersion current type: 'PharoDev' and you can change the suffix as well, but personally i would not use the date in the image name. cheers, Mike 2010/1/10 Mariano Martinez Peck <marianopeck@gmail.com>:
Hi folks:Â If you take a Dev image and go to " System->About "Â you get something like:
PharoCore1.0rc1 Latest update: #10505
However, I would like to show something like this for example:
Pharo1.0-10505-rc1dev10.01.1 PharoCore1.0rc1 Latest update: #10505
Do you know how we can change this? How can I set that name when building a PharoDev image?
Is this related to SystemVersion ??
We need to have this fixed for the official 1.0 release.
Cheers
Mariano
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Sun, Jan 10, 2010 at 3:23 PM, Michael Roberts <mike@mjr104.co.uk> wrote:
Hi you need to set
SystemVersion current type: 'Pharo'
to change the core image it is built from to be Pharo. or if we abandon the distinction
SystemVersion current type: 'PharoDev'
Ok...the problem is that I have just checked and this changes are only in 1.1 isn't it ? :( So...what we do ? we keep like this until 1.1 ?
and you can change the suffix as well, but personally i would not use the date in the image name.
For the date you refer to year, month and number of version inside the month ?
cheers, Mike
2010/1/10 Mariano Martinez Peck <marianopeck@gmail.com>:
Hi folks: If you take a Dev image and go to " System->About " you get something like:
PharoCore1.0rc1 Latest update: #10505
However, I would like to show something like this for example:
Pharo1.0-10505-rc1dev10.01.1 PharoCore1.0rc1 Latest update: #10505
Do you know how we can change this? How can I set that name when building a PharoDev image?
Is this related to SystemVersion ??
We need to have this fixed for the official 1.0 release.
Cheers
Mariano
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
2010/1/10 Mariano Martinez Peck <marianopeck@gmail.com>:
Ok...the problem is that I have just checked and this changes are only in 1.1 isn't it ?
:(Â Â Â So...what we do ? we keep like this until 1.1 ?
oh sorry yes they are only in 1.1. You just need to change version: string using some string manipulation. If you keep it in the same format it will parse correctly by code that expects the 1.1 format. On principle I did not backport the SystemVersion changes behaviour to 1.0 since it was already at the end of the cycle. However i just migrated the data to work across core branches.
and you can change the suffix as well, but personally i would not use the date in the image name.
For the date you refer to year, month and number of version inside the month ?
yes I think it is too complicated a version scheme. The dev tag is also synonymous with Pharo. so if your Pharo image is currently Pharo1.0-10505-rc1dev10.01.1 I would call it Pharo-1.0-10505-rc1. This is the same scheme that the core image uses, and Pharo 1.1 will have this behaviour already using #imageVersionString since it is in 1.1. thanks, Mike
On Sun, Jan 10, 2010 at 3:38 PM, Michael Roberts <mike@mjr104.co.uk> wrote:
2010/1/10 Mariano Martinez Peck <marianopeck@gmail.com>:
Ok...the problem is that I have just checked and this changes are only in 1.1 isn't it ?
:( So...what we do ? we keep like this until 1.1 ?
oh sorry yes they are only in 1.1. You just need to change version: string using some string manipulation. If you keep it in the same format it will parse correctly by code that expects the 1.1 format. On principle I did not backport the SystemVersion changes behaviour to 1.0 since it was already at the end of the cycle. However i just migrated the data to work across core branches.
and you can change the suffix as well, but personally i would not use the date in the image name.
For the date you refer to year, month and number of version inside the
month
?
yes I think it is too complicated a version scheme. The dev tag is also synonymous with Pharo.
so if your Pharo image is currently Pharo1.0-10505-rc1dev10.01.1 I would call it Pharo-1.0-10505-rc1. This is the same scheme that the core image uses, and Pharo 1.1 will have this behaviour already using #imageVersionString since it is in 1.1.
That's cool. I evaluate: SystemVersion current version: 'Pharo-1.0-10505-rc1' And seems to be almost what I want. It would be cool (maybe not for 1.0, but for 1.1) if we can see not only the version of Pharo, but also opf the pharoCore...So, SystemVersion could understand: coreVersion: and version: Then in System -> About, if I am in a core image I would see: PharoCore1.0rc1 Latest update: #10505 And if I am in Pharo I would see Pharo1.0-10505-rc1dev10.01.1 PharoCore1.0rc1 Latest update: #10505 Right now, with what you told me is enought for 1.0, but maybe for 1.1 would be cool to have that. what do you think ? cheers mariano
thanks, Mike
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
I had imagined the update number of Pharo and PharoCore would be the same? do you need to know any more about the core image? ...we could embed the core's SystemVersion in the Pharo image. version iVar will be deprecated when I get around to it. did you mean putting behaviour on the instance side? I would not, but do something like "during Pharo build...." SystemVersion core: SystemVersion current copy. "Make image Pharo" SystemVersion current type: 'Pharo'; suffix: 'rc1' "etc" and then in the about dialog you can access SystemVersion core & SystemVersion current. This is at the expense of a new class variable. however, i'm not sure if it's really needed. Could the release notes tell you where the image comes from? cheers, Mike
Ok...the problem is that I have just checked and this changes are only in 1.1 isn't it ?
:(Â Â Â So...what we do ? we keep like this until 1.1 ?
oh sorry yes they are only in 1.1. Â You just need to change version: string using some string manipulation. Â If you keep it in the same format it will parse correctly by code that expects the 1.1 format. On principle I did not backport the SystemVersion changes behaviour to 1.0 since it was already at the end of the cycle. However i just migrated the data to work across core branches.
and you can change the suffix as well, but personally i would not use the date in the image name.
For the date you refer to year, month and number of version inside the month ?
yes I think it is too complicated a version scheme. The dev tag is also synonymous with Pharo.
so if your Pharo image is currently Pharo1.0-10505-rc1dev10.01.1 I would call it Pharo-1.0-10505-rc1. This is the same scheme that the core image uses, and Pharo 1.1 will have this behaviour already using #imageVersionString since it is in 1.1.
That's cool. I evaluate:
SystemVersion current version: 'Pharo-1.0-10505-rc1'
And seems to be almost what I want. It would be cool (maybe not for 1.0, but for 1.1) if we can see not only the version of Pharo, but also opf the pharoCore...So, SystemVersion could understand:
coreVersion: Â and version:
Then in System -> About, if I am in a core image I would see:
 PharoCore1.0rc1 Latest update: #10505
And if I am in Pharo I would see
Pharo1.0-10505-rc1dev10.01.1 PharoCore1.0rc1 Latest update: #10505
Right now, with what you told me is enought for 1.0, but maybe for 1.1 would be cool to have that.
what do you think ?
cheers
mariano
thanks, Mike
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Sun, Jan 10, 2010 at 4:34 PM, Michael Roberts <mike@mjr104.co.uk> wrote:
I had imagined the update number of Pharo and PharoCore would be the same? do you need to know any more about the core image?
I really don't know. But for example, but happens with after DevImage someone do a System Update and updates the core ? I think that maybe we should take a decision if this system update will be allowed or not in a Pharo image.
...we could embed the core's SystemVersion in the Pharo image. version iVar will be deprecated when I get around to it. did you mean putting behaviour on the instance side? I would not, but do something like
"during Pharo build...." SystemVersion core: SystemVersion current copy.
"Make image Pharo" SystemVersion current type: 'Pharo'; suffix: 'rc1' "etc"
and then in the about dialog you can access SystemVersion core & SystemVersion current. This is at the expense of a new class variable.
Ok.
however, i'm not sure if it's really needed.
Me neither. Opinions ?
Could the release notes tell you where the image comes from?
I can put in the changelog whatever I want. So, in the changelog I would be able to put something like 'Pharo-1.0-10505-rc1 The problem is that most people don't look at that but to the System -> About cheers,
Mike
Ok...the problem is that I have just checked and this changes are only in 1.1 isn't it ?
:( So...what we do ? we keep like this until 1.1 ?
oh sorry yes they are only in 1.1. You just need to change version: string using some string manipulation. If you keep it in the same format it will parse correctly by code that expects the 1.1 format. On principle I did not backport the SystemVersion changes behaviour to 1.0 since it was already at the end of the cycle. However i just migrated the data to work across core branches.
and you can change the suffix as well, but personally i would not use the date in the image name.
For the date you refer to year, month and number of version inside the month ?
yes I think it is too complicated a version scheme. The dev tag is also synonymous with Pharo.
so if your Pharo image is currently Pharo1.0-10505-rc1dev10.01.1 I would call it Pharo-1.0-10505-rc1. This is the same scheme that the core image uses, and Pharo 1.1 will have this behaviour already using #imageVersionString since it is in 1.1.
That's cool. I evaluate:
SystemVersion current version: 'Pharo-1.0-10505-rc1'
And seems to be almost what I want. It would be cool (maybe not for 1.0, but for 1.1) if we can see not only the version of Pharo, but also opf the pharoCore...So, SystemVersion could understand:
coreVersion: and version:
Then in System -> About, if I am in a core image I would see:
PharoCore1.0rc1 Latest update: #10505
And if I am in Pharo I would see
Pharo1.0-10505-rc1dev10.01.1 PharoCore1.0rc1 Latest update: #10505
Right now, with what you told me is enought for 1.0, but maybe for 1.1 would be cool to have that.
what do you think ?
cheers
mariano
thanks, Mike
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Em 10/01/2010 13:04, Mariano Martinez Peck < marianopeck@gmail.com > escreveu:
On Sun, Jan 10, 2010 at 3:38 PM, Michael Roberts <mike@mjr104.co.uk> wrote:
2010/1/10 Mariano Martinez Peck <marianopeck@gmail.com>:
[snipped]
and you can change the suffix as well, but personally i would not use the date in the image name.
For the date you refer to year, month and number of version inside the month ?
yes I think it is too complicated a version scheme. The dev tag is also synonymous with Pharo. so if your Pharo image is currently Pharo1.0-10505-rc1dev10.01.1 I would call it Pharo-1.0-10505-rc1. This is the same scheme that the core image uses, and Pharo 1.1 will have this behaviour already using #imageVersionString since it is in 1.1.
That's cool. I evaluate: SystemVersion current version: 'Pharo-1.0-10505-rc1' And seems to be almost what I want. It would be cool (maybe not for 1.0, but for 1.1) if we can see not only the version of Pharo, but also opf the pharoCore...So, SystemVersion could understand: coreVersion: and version: Then in System -> About, if I am in a core image I would see:
PharoCore1.0rc1 Latest update: #10505
OK.
And if I am in Pharo I would see Pharo1.0-10505-rc1dev10.01.1
Isn't this ^^^^^ completely redundant with:
PharoCore1.0rc1 Latest update: #10505 <<<<<<<<<--- this?
-- Cesar Rabak
On Sun, Jan 10, 2010 at 8:37 PM, <csrabak@bol.com.br> wrote:
Em 10/01/2010 13:04, Mariano Martinez Peck < marianopeck@gmail.com > escreveu:
On Sun, Jan 10, 2010 at 3:38 PM, Michael Roberts <mike@mjr104.co.uk> wrote:
2010/1/10 Mariano Martinez Peck <marianopeck@gmail.com>:
[snipped]
and you can change the suffix as well, but personally i would not use the date in the image name.
For the date you refer to year, month and number of version inside the month ?
yes I think it is too complicated a version scheme. The dev tag is also synonymous with Pharo. so if your Pharo image is currently Pharo1.0-10505-rc1dev10.01.1 I would call it Pharo-1.0-10505-rc1. This is the same scheme that the core image uses, and Pharo 1.1 will have this behaviour already using #imageVersionString since it is in 1.1.
That's cool. I evaluate: SystemVersion current version: 'Pharo-1.0-10505-rc1' And seems to be almost what I want. It would be cool (maybe not for 1.0, but for 1.1) if we can see not only the version of Pharo, but also opf the pharoCore...So, SystemVersion could understand: coreVersion: and version: Then in System -> About, if I am in a core image I would see:
PharoCore1.0rc1 Latest update: #10505
OK.
And if I am in Pharo I would see Pharo1.0-10505-rc1dev10.01.1
Isn't this ^^^^^ completely redundant with:
PharoCore1.0rc1 Latest update: #10505 <<<<<<<<<--- this?
the problem is what I have already said. If the user did a system update, the core will be higher that the dev image, and not the same. Maybe we can just don't care about this case or disable the system update in dev as we are discussing in another thread.
-- Cesar Rabak
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Em 10/01/2010 17:46, Mariano Martinez Peck <marianopeck@gmail.com> escreveu:
On Sun, Jan 10, 2010 at 8:37 PM, <csrabak@bol.com.br> wrote: Em 10/01/2010 13:04, Mariano Martinez Peck <marianopeck@gmail.com> escreveu:
PharoCore1.0rc1 Latest update: #10505
OK.
And if I am in Pharo I would see Pharo1.0-10505-rc1dev10.01.1 Isn't this ^^^^^ completely redundant with:
PharoCore1.0rc1 Latest update: #10505 <<<<<<<<<--- this?
the problem is what I have already said. If the user did a system update, the core will be higher that the dev image, and not the same.
I'm not so sure if I undertand this in full, so I'll test my understanding: Do your assertion above means that an hypothetical: Pharo1.0-10505-rc1dev10.01.1 that after some updates ends up reponding in System->About this: Pharo1.0-10505-rc1dev10.01.1 PharoCore1.0rc1 Latest update: #10510 You say that it would be *different* than a brand new downloaded: Pharo1.0-10510-rc1dev10.01.1 PharoCore1.0rc1 Latest update: #10510 Is it?
Maybe we can just don't care about this case or disable the system update in dev as we are discussing in another thread.
As an after thought after seeing other posts on the issue, I think more than a generic warning that "may break the image" the Monticello comments and/or a simple explanation on the reasons and affected packages *before* the update starts with an option to proceed or abort is much in need. -- Cesar Rabak
On Sun, Jan 10, 2010 at 9:10 PM, <csrabak@bol.com.br> wrote:
Em 10/01/2010 17:46, Mariano Martinez Peck <marianopeck@gmail.com> escreveu:
On Sun, Jan 10, 2010 at 8:37 PM, <csrabak@bol.com.br> wrote: Em 10/01/2010 13:04, Mariano Martinez Peck <marianopeck@gmail.com> escreveu:
PharoCore1.0rc1 Latest update: #10505
OK.
And if I am in Pharo I would see Pharo1.0-10505-rc1dev10.01.1 Isn't this ^^^^^ completely redundant with:
PharoCore1.0rc1 Latest update: #10505 <<<<<<<<<--- this?
the problem is what I have already said. If the user did a system update, the core will be higher that the dev image, and not the same.
I'm not so sure if I undertand this in full, so I'll test my understanding:
Do your assertion above means that an hypothetical:
Pharo1.0-10505-rc1dev10.01.1 that after some updates ends up reponding in System->About this:
Pharo1.0-10505-rc1dev10.01.1 PharoCore1.0rc1 Latest update: #10510
You say that it would be *different* than a brand new downloaded:
Pharo1.0-10510-rc1dev10.01.1 PharoCore1.0rc1 Latest update: #10510
Is it?
Exactly. Maybe is just a little detail. I don't know.
Maybe we can just don't care about this case or disable the system update in dev as we are discussing in another thread.
As an after thought after seeing other posts on the issue, I think more than a generic warning that "may break the image" the Monticello comments and/or a simple explanation on the reasons and affected packages *before* the update starts with an option to proceed or abort is much in need.
Yes, maybe. Then thing is that I am not sure in which cases it would break. Only in overrides? How many overrides do we have from external pacakges in Core stuff? I have no idea.
-- Cesar Rabak
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Em 10/01/2010 18:30, Mariano Martinez Peck <marianopeck@gmail.com> escreveu:
On Sun, Jan 10, 2010 at 9:10 PM, <csrabak@bol.com.br> wrote: [snipped]
I'm not so sure if I undertand this in full, so I'll test my understanding: Do your assertion above means that an hypothetical:
Pharo1.0-10505-rc1dev10.01.1 that after some updates ends up reponding in System->About this:
Pharo1.0-10505-rc1dev10.01.1 PharoCore1.0rc1 Latest update: #10510
You say that it would be *different* than a brand new downloaded: Pharo1.0-10510-rc1dev10.01.1 PharoCore1.0rc1 Latest update: #10510 Is it?
Exactly. Maybe is just a little detail. I don't know.
[snipped]
As an after thought after seeing other posts on the issue, I think more than a generic warning that "may break the image" the Monticello comments and/or a simple explanation on the reasons and affected packages *before* the update starts with an option to proceed or abort is much in need.
Yes, maybe. Then thing is that I am not sure in which cases it would break. Only in overrides? How many overrides do we have from external pacakges in Core stuff? I have no idea.
Considering both comments above, I would say we're going to have a not cool system. If this non determinism is left in our updating mechanism, more and more we'll have bug reports answered as "could not reproduce" or similar and the perceived quality of Pharo as a programming tool will suffer. I understand the issue isn't small potatoes but we should keep it in mind and find all opportunities to have this streamlined. As a counter measure, a built image could have a kind of history log of changesets zeroed and as one applies updates, slices, and load packages, this info could become available (as an adjunct to the debug trace) to help to backtrack the steps to reproduce the reported issue. HTH -- Cesar Rabak PS.: Before Stef puts a line asking for code, I believe we already have the machinary for this available, if this is not the case, then we'll need to put code in!
I'm afraid i've got rather lost in this thread.
 As an after thought after seeing other posts on the issue, I think  more  than  a  generic  warning  that "may  break  the  image"  the  Monticello comments and/or a  simple explanation on the reasons and  affected  packages *before*  the update  starts with  an  option to  proceed or abort is much in need.
 Yes, maybe.  Then thing  is that I  am not  sure in which  cases it would break. Only  in overrides? How many overrides  do we have from external pacakges in Core stuff?  I have no idea.
I think given that we are at a very early stage of building the Pharo image from PharoCore i.e Metacello just coming on etc, we should simplify the concerns above. Basically we should only build Pharo on top of a known PharoCore. Just because packages don't contain overrides does not imply that moving the core image will break packages on top. Don't offer such a feature, and then worry about what will happen. Part of the Pharo build script should set a flag that prevents system update in the short term. Longer term we should switch the available update mechanism to #loadLatest on the ConfigurationOfPharo. There is then one System update feature, but different implementation in Pharo vs PharoCore. cheers, Mike
On Mon, Jan 11, 2010 at 11:06 PM, Michael Roberts <mike@mjr104.co.uk> wrote:
I'm afraid i've got rather lost in this thread.
As an after thought after seeing other posts on the issue, I think more than a generic warning that "may break the image" the Monticello comments and/or a simple explanation on the reasons and affected packages *before* the update starts with an option to proceed or abort is much in need.
Yes, maybe. Then thing is that I am not sure in which cases it would break. Only in overrides? How many overrides do we have from external pacakges in Core stuff? I have no idea.
I think given that we are at a very early stage of building the Pharo image from PharoCore i.e Metacello just coming on etc, we should simplify the concerns above.
Basically we should only build Pharo on top of a known PharoCore. Just because packages don't contain overrides does not imply that moving the core image will break packages on top. Don't offer such a feature, and then worry about what will happen.
Part of the Pharo build script should set a flag that prevents system update in the short term.
Ok....it seems all agree more or less in disable it. I like when we take decisions :) Now...can someone help me with this? It takes too much time to build the images, and congs, etc... I would appreciate if someone can do it and let me know how to call it from the build script. I think it should be in Utilities >> updateFromServer But it would be cool to disable from the menu also. Or maybe, let the menu but bring a popup explaining that it is disable, and why it is. I opened: http://code.google.com/p/pharo/issues/detail?id=1779 It would be really cool to have this done before the next dev image :) Thanks Mariano Longer term we should switch the available
update mechanism to #loadLatest on the ConfigurationOfPharo. There is then one System update feature, but different implementation in Pharo vs PharoCore.
cheers, Mike
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
El lun, 11-01-2010 a las 22:06 +0000, Michael Roberts escribió:
I'm afraid i've got rather lost in this thread.
As an after thought after seeing other posts on the issue, I think more than a generic warning that "may break the image" the Monticello comments and/or a simple explanation on the reasons and affected packages *before* the update starts with an option to proceed or abort is much in need.
Yes, maybe. Then thing is that I am not sure in which cases it would break. Only in overrides? How many overrides do we have from external pacakges in Core stuff? I have no idea.
I think given that we are at a very early stage of building the Pharo image from PharoCore i.e Metacello just coming on etc, we should simplify the concerns above.
Basically we should only build Pharo on top of a known PharoCore. Just because packages don't contain overrides does not imply that moving the core image will break packages on top. Don't offer such a feature, and then worry about what will happen.
Part of the Pharo build script should set a flag that prevents system update in the short term. Longer term we should switch the available update mechanism to #loadLatest on the ConfigurationOfPharo. There is then one System update feature, but different implementation in Pharo vs PharoCore.
So the vote is for disabled for now?
cheers, Mike
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Miguel Cobá http://miguel.leugim.com.mx
2010/1/11 Miguel Enrique Cobá Martinez <miguel.coba@gmail.com>
El lun, 11-01-2010 a las 22:06 +0000, Michael Roberts escribió:
I'm afraid i've got rather lost in this thread.
As an after thought after seeing other posts on the issue, I think more than a generic warning that "may break the image" the Monticello comments and/or a simple explanation on the reasons and affected packages *before* the update starts with an option to proceed or abort is much in need.
Yes, maybe. Then thing is that I am not sure in which cases it would break. Only in overrides? How many overrides do we have from external pacakges in Core stuff? I have no idea.
I think given that we are at a very early stage of building the Pharo image from PharoCore i.e Metacello just coming on etc, we should simplify the concerns above.
Basically we should only build Pharo on top of a known PharoCore. Just because packages don't contain overrides does not imply that moving the core image will break packages on top. Don't offer such a feature, and then worry about what will happen.
Part of the Pharo build script should set a flag that prevents system update in the short term. Longer term we should switch the available update mechanism to #loadLatest on the ConfigurationOfPharo. There is then one System update feature, but different implementation in Pharo vs PharoCore.
So the vote is for disabled for now?
Yes. And this is cool because we have to put focus in to make Pharo images more stable. We cannot introduce such a feature when we are not even stable with Dev images. Let's go step by step. Once we get stable Dev images, good processes and package managment, then we can review this stuff about updating. Do you want to do it ? ;)
cheers, Mike
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Miguel Cobá http://miguel.leugim.com.mx
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
El lun, 11-01-2010 a las 23:41 +0100, Mariano Martinez Peck escribió:
2010/1/11 Miguel Enrique Cobá Martinez <miguel.coba@gmail.com> El lun, 11-01-2010 a las 22:06 +0000, Michael Roberts escribió: > I'm afraid i've got rather lost in this thread. > > >> As an after thought after seeing other posts on the issue, I think > >> more than a generic warning that "may break the image" the > >> Monticello comments and/or a simple explanation on the reasons and > >> affected packages *before* the update starts with an option to > >> proceed or abort is much in need. > >> > >> > >> Yes, maybe. Then thing is that I am not sure in which cases it > >> would break. Only in overrides? How many overrides do we have from > >> external pacakges in Core stuff? I have no idea. > > > > I think given that we are at a very early stage of building the Pharo > image from PharoCore i.e Metacello just coming on etc, we should > simplify the concerns above. > > Basically we should only build Pharo on top of a known PharoCore. Just > because packages don't contain overrides does not imply that moving > the core image will break packages on top. Don't offer such a feature, > and then worry about what will happen. > > Part of the Pharo build script should set a flag that prevents system > update in the short term. Longer term we should switch the available > update mechanism to #loadLatest on the ConfigurationOfPharo. There is > then one System update feature, but different implementation in Pharo > vs PharoCore. >
So the vote is for disabled for now?
Yes. And this is cool because we have to put focus in to make Pharo images more stable. We cannot introduce such a feature when we are not even stable with Dev images. Let's go step by step. Once we get stable Dev images, good processes and package managment, then we can review this stuff about updating.
Do you want to do it ? ;)
Yes, I will do it, but tomorrow. My idea is to make this a preference and the the build script just disable it. More tomorrow. Cheers
> cheers, > Mike > > _______________________________________________ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Miguel Cobá http://miguel.leugim.com.mx
_______________________________________________
Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Miguel Cobá http://miguel.leugim.com.mx
2010/1/12 Miguel Enrique Cobá Martinez <miguel.coba@gmail.com>
El lun, 11-01-2010 a las 23:41 +0100, Mariano Martinez Peck escribió:
2010/1/11 Miguel Enrique Cobá Martinez <miguel.coba@gmail.com> El lun, 11-01-2010 a las 22:06 +0000, Michael Roberts escribió: > I'm afraid i've got rather lost in this thread. > > >> As an after thought after seeing other posts on the issue, I think > >> more than a generic warning that "may break the image" the > >> Monticello comments and/or a simple explanation on the reasons and > >> affected packages *before* the update starts with an option to > >> proceed or abort is much in need. > >> > >> > >> Yes, maybe. Then thing is that I am not sure in which cases it > >> would break. Only in overrides? How many overrides do we have from > >> external pacakges in Core stuff? I have no idea. > > > > I think given that we are at a very early stage of building the Pharo > image from PharoCore i.e Metacello just coming on etc, we should > simplify the concerns above. > > Basically we should only build Pharo on top of a known PharoCore. Just > because packages don't contain overrides does not imply that moving > the core image will break packages on top. Don't offer such a feature, > and then worry about what will happen. > > Part of the Pharo build script should set a flag that prevents system > update in the short term. Longer term we should switch the available > update mechanism to #loadLatest on the ConfigurationOfPharo. There is > then one System update feature, but different implementation in Pharo > vs PharoCore. >
So the vote is for disabled for now?
Yes. And this is cool because we have to put focus in to make Pharo images more stable. We cannot introduce such a feature when we are not even stable with Dev images. Let's go step by step. Once we get stable Dev images, good processes and package managment, then we can review this stuff about updating.
Do you want to do it ? ;)
Yes, I will do it, but tomorrow.
Cool!! No hurry..
My idea is to make this a preference and the the build script just disable it.
Be careful with the preferences....remember all the changes in 1.1
More tomorrow.
Cheers
> cheers, > Mike > > _______________________________________________ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr >
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Miguel Cobá http://miguel.leugim.com.mx
_______________________________________________
Pharo-project mailing list Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Miguel Cobá http://miguel.leugim.com.mx
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Yes, I will do it, but tomorrow.
Cool!! No hurry..
Well, not precisely "tomorrow" but a few days later is done: http://code.google.com/p/pharo/issues/detail?id=1841
My idea is to make this a preference and the the build script just disable it.
It is a preference for PharoCore 1.0. In your ConfigurationOfPharo add somewhere: Preferences disable: #showUpdateOptionInWorldMenu to drop the option from the System -> Software update Of course, this only hides the option from the users but don't prohibits the image from being updated, just that the update must be done manually by evaluating: Utilities updateFromServer in a workspace. This way, a user that want to update their image can do it but most users won't see the option in the menu. For PharoCore 1.1 I will make the analogous change but using the Settings framework... but tomorrow :) Cheers
Be careful with the preferences....remember all the changes in 1.1
More tomorrow.
Cheers
> > > cheers, > > Mike > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project@lists.gforge.inria.fr > > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > -- > Miguel Cobá > http://miguel.leugim.com.mx > > > _______________________________________________ > > > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Miguel Cobá http://miguel.leugim.com.mx
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Miguel Cobá http://miguel.leugim.com.mx
+1
Yes. And this is cool because we have to put focus in to make Pharo images more stable. We cannot introduce such a feature when we are not even stable with Dev images. Let's go step by step. Once we get stable Dev images, good processes and package managment, then we can review this stuff about updating.
PS.: Before Stef puts a line asking for code, I believe we already have the machinary for this available, if this is not the case, then we'll need to put code in!
he has a google bot that answers that. It checks for certain words like "wish" "would like" and if true, send the email :)
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
yes I think it is too complicated a version scheme. The dev tag is also synonymous with Pharo.
so if your Pharo image is currently Pharo1.0-10505-rc1dev10.01.1 I would call it Pharo-1.0-10505-rc1. This is the same scheme that the
The is Pharo-1.0-10505-rc1 or it should be Pharo-1.0-10505rc1 (note the - between 10505 and rc1). I ask because the PharoCore 10502 was released as PharoCore-1.0-10502rc1. I can ask Adrian so that the next PharoCore 1.0 be like: Pharo-1.0-10XXX-rc2 I know...it is a little detail.but...jhhahahha core image uses, and Pharo 1.1 will have this behaviour already using
#imageVersionString since it is in 1.1.
thanks, Mike
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
El dom, 10-01-2010 a las 23:34 +0100, Mariano Martinez Peck escribió:
yes I think it is too complicated a version scheme. The dev tag is also synonymous with Pharo.
so if your Pharo image is currently Pharo1.0-10505-rc1dev10.01.1 I would call it Pharo-1.0-10505-rc1. This is the same scheme that the
The is Pharo-1.0-10505-rc1 or it should be Pharo-1.0-10505rc1 (note the - between 10505 and rc1). I ask because the PharoCore 10502 was released as PharoCore-1.0-10502rc1. I can ask Adrian so that the next PharoCore 1.0 be like: Pharo-1.0-10XXX-rc2
I vote for having the tokens separated by "-", so: Pharo-1.0-10505-rc1 Also, the original proposal for the name format is here: http://n2.nabble.com/Pharo-name-format-tp3365418p3365418.html Cheers
I know...it is a little detail.but...jhhahahha
core image uses, and Pharo 1.1 will have this behaviour already using #imageVersionString since it is in 1.1.
thanks, Mike
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Miguel Cobá http://miguel.leugim.com.mx
2010/1/11 Miguel Enrique Cobá Martinez <miguel.coba@gmail.com>
El dom, 10-01-2010 a las 23:34 +0100, Mariano Martinez Peck escribió:
yes I think it is too complicated a version scheme. The dev tag is also synonymous with Pharo.
so if your Pharo image is currently Pharo1.0-10505-rc1dev10.01.1 I would call it Pharo-1.0-10505-rc1. This is the same scheme that the
The is Pharo-1.0-10505-rc1 or it should be Pharo-1.0-10505rc1 (note the - between 10505 and rc1). I ask because the PharoCore 10502 was released as PharoCore-1.0-10502rc1. I can ask Adrian so that the next PharoCore 1.0 be like: Pharo-1.0-10XXX-rc2
I vote for having the tokens separated by "-", so:
Pharo-1.0-10505-rc1
Also, the original proposal for the name format is here:
http://n2.nabble.com/Pharo-name-format-tp3365418p3365418.html
Excellent. I have already done that. Next Dev image, when you do System -> About will show, for example: Pharo-1.0-10505-rc1 :) Cheers Mariano
Cheers
I know...it is a little detail.but...jhhahahha
core image uses, and Pharo 1.1 will have this behaviour already using #imageVersionString since it is in 1.1.
thanks, Mike
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Miguel Cobá http://miguel.leugim.com.mx
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
participants (5)
-
csrabak＠bol.com.br -
Mariano Martinez Peck -
Michael Roberts -
Miguel Enrique Cobá Martinez -
Stéphane Ducasse