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 [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
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 <[hidden email]>: > 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 > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
On Sun, Jan 10, 2010 at 3:23 PM, Michael Roberts <[hidden email]> wrote: Hi you need to set 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 For the date you refer to year, month and number of version inside the month ? cheers, _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
2010/1/10 Mariano Martinez Peck <[hidden email]>:
> > 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 _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
On Sun, Jan 10, 2010 at 3:38 PM, Michael Roberts <[hidden email]> wrote:
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, _______________________________________________ Pharo-project mailing list [hidden email] 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 >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
On Sun, Jan 10, 2010 at 4:34 PM, Michael Roberts <[hidden email]> wrote: I had imagined the update number of Pharo and PharoCore would be the 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. Ok.
Me neither. Opinions ? Could the release notes 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, _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
In reply to this post by Mariano Martinez Peck
Em 10/01/2010 13:04, Mariano Martinez Peck < [hidden email] > escreveu:
> On Sun, Jan 10, 2010 at 3:38 PM, Michael Roberts > <[hidden email]> wrote: > > 2010/1/10 Mariano Martinez Peck <[hidden email]>: > [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 _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
On Sun, Jan 10, 2010 at 8:37 PM, <[hidden email]> wrote: Em 10/01/2010 13:04, Mariano Martinez Peck < [hidden email] > escreveu: 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. -- _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Em 10/01/2010 17:46, Mariano Martinez Peck <[hidden email]> escreveu:
> On Sun, Jan 10, 2010 at 8:37 PM, <[hidden email]> wrote: > Em 10/01/2010 13:04, Mariano Martinez Peck <[hidden email]> > 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 _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
On Sun, Jan 10, 2010 at 9:10 PM, <[hidden email]> wrote: Em 10/01/2010 17:46, Mariano Martinez Peck <[hidden email]> escreveu: Exactly. Maybe is just a little detail. I don't know.
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.
_______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
In reply to this post by Michael Roberts-2
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 _______________________________________________ Pharo-project mailing list [hidden email] 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 > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Miguel Cobá http://miguel.leugim.com.mx _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
2010/1/11 Miguel Enrique Cobá Martinez <[hidden email]> El dom, 10-01-2010 a las 23:34 +0100, Mariano Martinez Peck escribió: 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 _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
In reply to this post by Mariano Martinez Peck
Em 10/01/2010 18:30, Mariano Martinez Peck <[hidden email]> escreveu:
> On Sun, Jan 10, 2010 at 9:10 PM, <[hidden email]> 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. > > > > 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! _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
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 _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
On Mon, Jan 11, 2010 at 11:06 PM, Michael Roberts <[hidden email]> wrote: I'm afraid i've got rather lost in this thread. 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 _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
In reply to this post by Michael Roberts-2
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 > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Miguel Cobá http://miguel.leugim.com.mx _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
In reply to this post by csrabak
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 [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
In reply to this post by Miguel Cobá
2010/1/11 Miguel Enrique Cobá Martinez <[hidden email]> El lun, 11-01-2010 a las 22:06 +0000, Michael Roberts escribió: 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 ? ;)
_______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Free forum by Nabble | Edit this page |