another thought about the #stable version
Locked
another thought about the #stable version
 
|
As I am getting close to pushing symbolic versions out the door, I
thought it was worth sharing another thought on the #stable version ... The thought is that when talking about a stable version for Pharo1.2 or Pharo1.3 coming up. I think that it should be valid to define the stable version for a platform version that is under development as #development. So the following should be used for the Pharo1.2 versions of projects until the platform and the project has settled down: stable: spec <symbolicVersion: #'stable'> spec for: #'pharo1.0.x' version: '1.1.3'. spec for: #'pharo1.1.x' version: '1.1.5'. spec for: #'pharo1.2.x' version: #development. For unstable platform versions, we still need to nominate a version that is "stable" relative to the platform version and for man yprojects relative to Pharo1.2 #development might be the best answer as constant updates may be needed as the Pharo1.2 itself moves "out from under" a functional release. Note that a #stable version should only be specified if there is an effort to port the project to Pharo1.2 and if the best answer for the "stable" version is #development then that is much better than no version. Dale |
Re: another thought about the #stable version
|
|
Makes sense.
El lun, 17-01-2011 a las 10:10 -0800, Dale escribió: > As I am getting close to pushing symbolic versions out the door, I > thought it was worth sharing another thought on the #stable > version ... The thought is that when talking about a stable version > for Pharo1.2 or Pharo1.3 coming up. I think that it should be valid to > define the stable version for a platform version that is under > development as #development. > > So the following should be used for the Pharo1.2 versions of projects > until the platform and the project has settled down: > > stable: spec > <symbolicVersion: #'stable'> > spec for: #'pharo1.0.x' version: '1.1.3'. > spec for: #'pharo1.1.x' version: '1.1.5'. > spec for: #'pharo1.2.x' version: #development. > > For unstable platform versions, we still need to nominate a version > that is "stable" relative to the platform version and for man > yprojects relative to Pharo1.2 #development might be the best answer > as constant updates may be needed as the Pharo1.2 itself moves "out > from under" a functional release. > > Note that a #stable version should only be specified if there is an > effort to port the project to Pharo1.2 and if the best answer for the > "stable" version is #development then that is much better than no > version. > > Dale -- Miguel Cobá http://twitter.com/MiguelCobaMtz http://miguel.leugim.com.mx |
Re: another thought about the #stable version
|
|
In reply to this post by Dale Henrichs
On Mon, Jan 17, 2011 at 7:10 PM, Dale <[hidden email]> wrote: As I am getting close to pushing symbolic versions out the door, I I agree at some point. I agree and I like the idea that Metacello let me use ANOTHER symbolic/literal version inside another symbolic version, like in this case with the #development However, and this is only from my point of view, putting #development as stable may not be correct. I mean, when you use #development, it is that, it is in development -> probably unustable. So......FROM MY POINT OF VIEW, #stable needs to ALWAYS be stalbe or throw an error. If I maintain SqueakDBX and even if there is a #development version, I wouldn't put such as stable in Pharo 1.2, I would throw an error instead saying there is not yet a stable version, but that you may try to use the latestVersion for example. So I would like to do: stable: spec <symbolicVersion: #'stable'> spec for: #'pharo1.0.x' version: '1.1.3'. spec for: #'pharo1.1.x' version: '1.1.5'. spec for: #'pharo1.2.x' do: [ Error signal: 'There is no stable version for Pharo 1.2. You may want to try blah... blah..' ]. Now, of course, there can be projects where each commit is considered stable (even if I don't believe on them). cheers mariano
|
Re: another thought about the #stable version
|
|
Mariano,
I understand your concern and I started this thread to discuss the issue ... My point is that we can't take the #stable symbolic version _name_ too literally. Again the name is #stable, but it's real meaning is "recommended version to load for a platform". For platform versions that are stable then the #stable version of a project is expected to be #stable. For unstable platform versions all bets are off. If you recall, not too long ago the way to get OmniBrowser to load into Pharo1.2 was to load the latest versions of all of the packages ... I think that specifying #stable as #bleedingEdge would be preferable in that case, because then the _users_ of the configuration don't have to guess or find out the special instructions for loading each project ... the rule is that if there is a #stable version defined, then that is the recommended version and if the platform itself is unstable, the everything must be taken with a grain of salt. The next logical step is to define the #stable version as the #development version ... one could use the literal version for a version whose blessing is #development, but I think that more information is conveyed by using #development and #bleedingEdge than using '1.2.3' (which happens to be a development version) ... Over the weekend, I loaded and tested Metacello in the absolute latest version of Pharo1.2beta and OmniBrowser loaded fine, but the whole windowing system was broken (something to do with shout problems) ... this morning I loaded Metacello into PharoCore-1.2beta-12294 (which isn't that old) and everything loaded fine,OB, the windowing system and OB-Metacello were functional ... So if I were to follow the meaning of stable too strictly I can't claim that Metacello is stable on Pharo1.2. But I am declaring that 1.0-beta.28 is the version to use on Pharo1.2 and if it happens to break then put that down to the instability of the platform version not the literal meaning of stable. I talk about one of my canoes being stable relative to another canoe, yet canoes are inherently unstable .... In the end I think that it is important that every developer define the #stable version of his project for the platforms that he is supporting the product on ... For GemTools I can't consider starting a port to a new version of Pharo until #stable versions of FFI, OB, Shout and HelpSystem show up and when they do I'm off to the races ... my code itself will definitely be affected by bugs that appear in the underlying projects, but if the fix isn't in my code, my users can just load the #stable version of GemTools (which would reference the #stable versions of the other projects) and take advantage of the bugfixes in other projects... Dale On 01/17/2011 12:19 PM, Mariano Martinez Peck wrote: > > > On Mon, Jan 17, 2011 at 7:10 PM, Dale <[hidden email] > <mailto:[hidden email]>> wrote: > > As I am getting close to pushing symbolic versions out the door, I > thought it was worth sharing another thought on the #stable > version ... The thought is that when talking about a stable version > for Pharo1.2 or Pharo1.3 coming up. I think that it should be valid to > define the stable version for a platform version that is under > development as #development. > > So the following should be used for the Pharo1.2 versions of projects > until the platform and the project has settled down: > > stable: spec > <symbolicVersion: #'stable'> > spec for: #'pharo1.0.x' version: '1.1.3'. > spec for: #'pharo1.1.x' version: '1.1.5'. > spec for: #'pharo1.2.x' version: #development. > > > I agree at some point. > I agree and I like the idea that Metacello let me use ANOTHER > symbolic/literal version inside another symbolic version, like in this > case with the #development > > However, and this is only from my point of view, putting #development as > stable may not be correct. I mean, when you use #development, it is > that, it is in development -> probably unustable. > So......FROM MY POINT OF VIEW, #stable needs to ALWAYS be stalbe or > throw an error. > > If I maintain SqueakDBX and even if there is a #development version, I > wouldn't put such as stable in Pharo 1.2, I would throw an error instead > saying there is not yet a stable version, but that you may try to use > the latestVersion for example. So I would like to do: > > stable: spec > <symbolicVersion: #'stable'> > spec for: #'pharo1.0.x' version: '1.1.3'. > spec for: #'pharo1.1.x' version: '1.1.5'. > spec for: #'pharo1.2.x' do: [ Error signal: 'There is no stable > version for Pharo 1.2. You may want to try blah... blah..' ]. > > Now, of course, there can be projects where each commit is considered > stable (even if I don't believe on them). > > cheers > > mariano > > > > For unstable platform versions, we still need to nominate a version > that is "stable" relative to the platform version and for man > yprojects relative to Pharo1.2 #development might be the best answer > as constant updates may be needed as the Pharo1.2 itself moves "out > from under" a functional release. > > Note that a #stable version should only be specified if there is an > effort to port the project to Pharo1.2 and if the best answer for the > "stable" version is #development then that is much better than no > version. > > Dale > > |
Re: another thought about the #stable version
|
|
In reply to this post by Miguel Cobá
+1
On Jan 17, 2011, at 7:23 PM, Miguel Cobá wrote: > Makes sense. > > El lun, 17-01-2011 a las 10:10 -0800, Dale escribió: >> As I am getting close to pushing symbolic versions out the door, I >> thought it was worth sharing another thought on the #stable >> version ... The thought is that when talking about a stable version >> for Pharo1.2 or Pharo1.3 coming up. I think that it should be valid to >> define the stable version for a platform version that is under >> development as #development. >> >> So the following should be used for the Pharo1.2 versions of projects >> until the platform and the project has settled down: >> >> stable: spec >> <symbolicVersion: #'stable'> >> spec for: #'pharo1.0.x' version: '1.1.3'. >> spec for: #'pharo1.1.x' version: '1.1.5'. >> spec for: #'pharo1.2.x' version: #development. >> >> For unstable platform versions, we still need to nominate a version >> that is "stable" relative to the platform version and for man >> yprojects relative to Pharo1.2 #development might be the best answer >> as constant updates may be needed as the Pharo1.2 itself moves "out >> from under" a functional release. >> >> Note that a #stable version should only be specified if there is an >> effort to port the project to Pharo1.2 and if the best answer for the >> "stable" version is #development then that is much better than no >> version. >> >> Dale > > -- > Miguel Cobá > http://twitter.com/MiguelCobaMtz > http://miguel.leugim.com.mx > > > |
Re: another thought about the #stable version
|
|
In reply to this post by Dale Henrichs
nice discussion.
Nothing simple in this world. I'm eager to see if we can produce repositories and publish config with all the required packages there. Stef On Jan 17, 2011, at 10:21 PM, Dale Henrichs wrote: > Mariano, > > I understand your concern and I started this thread to discuss the issue ... > > My point is that we can't take the #stable symbolic version _name_ too literally. Again the name is #stable, but it's real meaning is "recommended version to load for a platform". For platform versions that are stable then the #stable version of a project is expected to be #stable. For unstable platform versions all bets are off. > > If you recall, not too long ago the way to get OmniBrowser to load into Pharo1.2 was to load the latest versions of all of the packages ... I think that specifying #stable as #bleedingEdge would be preferable in that case, because then the _users_ of the configuration don't have to guess or find out the special instructions for loading each project ... the rule is that if there is a #stable version defined, then that is the recommended version and if the platform itself is unstable, the everything must be taken with a grain of salt. > > The next logical step is to define the #stable version as the #development version ... one could use the literal version for a version whose blessing is #development, but I think that more information is conveyed by using #development and #bleedingEdge than using '1.2.3' (which happens to be a development version) ... > > Over the weekend, I loaded and tested Metacello in the absolute latest version of Pharo1.2beta and OmniBrowser loaded fine, but the whole windowing system was broken (something to do with shout problems) ... this morning I loaded Metacello into PharoCore-1.2beta-12294 (which isn't that old) and everything loaded fine,OB, the windowing system and OB-Metacello were functional ... > > So if I were to follow the meaning of stable too strictly I can't claim that Metacello is stable on Pharo1.2. But I am declaring that 1.0-beta.28 is the version to use on Pharo1.2 and if it happens to break then put that down to the instability of the platform version not the literal meaning of stable. > > I talk about one of my canoes being stable relative to another canoe, yet canoes are inherently unstable .... > > In the end I think that it is important that every developer define the #stable version of his project for the platforms that he is supporting the product on ... > > For GemTools I can't consider starting a port to a new version of Pharo until #stable versions of FFI, OB, Shout and HelpSystem show up and when they do I'm off to the races ... my code itself will definitely be affected by bugs that appear in the underlying projects, but if the fix isn't in my code, my users can just load the #stable version of GemTools (which would reference the #stable versions of the other projects) and take advantage of the bugfixes in other projects... > > Dale > > On 01/17/2011 12:19 PM, Mariano Martinez Peck wrote: >> >> >> On Mon, Jan 17, 2011 at 7:10 PM, Dale <[hidden email] >> <mailto:[hidden email]>> wrote: >> >> As I am getting close to pushing symbolic versions out the door, I >> thought it was worth sharing another thought on the #stable >> version ... The thought is that when talking about a stable version >> for Pharo1.2 or Pharo1.3 coming up. I think that it should be valid to >> define the stable version for a platform version that is under >> development as #development. >> >> So the following should be used for the Pharo1.2 versions of projects >> until the platform and the project has settled down: >> >> stable: spec >> <symbolicVersion: #'stable'> >> spec for: #'pharo1.0.x' version: '1.1.3'. >> spec for: #'pharo1.1.x' version: '1.1.5'. >> spec for: #'pharo1.2.x' version: #development. >> >> >> I agree at some point. >> I agree and I like the idea that Metacello let me use ANOTHER >> symbolic/literal version inside another symbolic version, like in this >> case with the #development >> >> However, and this is only from my point of view, putting #development as >> stable may not be correct. I mean, when you use #development, it is >> that, it is in development -> probably unustable. >> So......FROM MY POINT OF VIEW, #stable needs to ALWAYS be stalbe or >> throw an error. >> >> If I maintain SqueakDBX and even if there is a #development version, I >> wouldn't put such as stable in Pharo 1.2, I would throw an error instead >> saying there is not yet a stable version, but that you may try to use >> the latestVersion for example. So I would like to do: >> >> stable: spec >> <symbolicVersion: #'stable'> >> spec for: #'pharo1.0.x' version: '1.1.3'. >> spec for: #'pharo1.1.x' version: '1.1.5'. >> spec for: #'pharo1.2.x' do: [ Error signal: 'There is no stable >> version for Pharo 1.2. You may want to try blah... blah..' ]. >> >> Now, of course, there can be projects where each commit is considered >> stable (even if I don't believe on them). >> >> cheers >> >> mariano >> >> >> >> For unstable platform versions, we still need to nominate a version >> that is "stable" relative to the platform version and for man >> yprojects relative to Pharo1.2 #development might be the best answer >> as constant updates may be needed as the Pharo1.2 itself moves "out >> from under" a functional release. >> >> Note that a #stable version should only be specified if there is an >> effort to port the project to Pharo1.2 and if the best answer for the >> "stable" version is #development then that is much better than no >> version. >> >> Dale >> >> > |
Re: another thought about the #stable version
|
|
In reply to this post by Mariano Martinez Peck
On 01/17/2011 12:19 PM, Mariano Martinez Peck wrote:
> > > > stable: spec > <symbolicVersion: #'stable'> > spec for: #'pharo1.0.x' version: '1.1.3'. > spec for: #'pharo1.1.x' version: '1.1.5'. > spec for: #'pharo1.2.x' do: [ Error signal: 'There is no stable > version for Pharo 1.2. You may want to try blah... blah..' ]. > The way to specify this in Metacello is the following: stable: spec <symbolicVersion: #'stable'> spec for: #'pharo1.0.x' version: '1.1.3'. spec for: #'pharo1.1.x' version: '1.1.5'. spec for: #'pharo1.2.x' version: #notDefined If you as the developer knows the formula for loading the project into Pharo1.2, then you should require a manual step ... specify the version to use right there in the specification for Pharo1.2...if the answer is latest version of each package then put #bleedingEdge, if the answer is latest development version, then put in #development, if the answer is a literal version, then put the literal version ... Keep in mind that the references from your project are not just from people doing direct loads, but from other configurations as well and "You may want to try blah... blah.." doesn't help ... Right now, let's forget about the meaning of the word stable and focus on the concept behind it ... I claim that it is important that every project define a "symbolic version formerly known as stable" for all of the platforms that they are actively supporting ... as soon as you have code that runs on Pharo1.2 well enough for it to be used then you should add set up a definition for Pharo1.2 in a "symbolic version formerly known as stable". Then users know to load "symbolic version formerly known as stable" to get the developers latest attempt and other projects that rely on your project can now consider supporting Pharo1.2 and by specifying their reliance in terms of a "symbolic version formerly known as stable" as they will leverage the bugfixes both up and down stream ... So I think the concept of well known version is important. Dale |
Re: another thought about the #stable version
|
|
In reply to this post by stephane ducasse-2
On 01/17/2011 01:40 PM, stephane ducasse wrote:
> nice discussion. > Nothing simple in this world. > I'm eager to see if we can produce repositories and publish config with all the required packages there. > > Stef Stef, I can set up experimental repositories on: http://a-bibliocello.gemstone.com/ Just let me know the names of the repositories that you'd like to use ... you can look at: http://a-bibliocello.gemstone.com/bibliocello/Pharo for some ideas about path names for the repositories. If you want to use a name that already exists that's not a problem, there's nothing permanent about the bibliocello site right now... Dale |
Re: another thought about the #stable version
|
|
> I can set up experimental repositories on:
> > http://a-bibliocello.gemstone.com/ > > Just let me know the names of the repositories that you'd like to use ... you can look at: > > http://a-bibliocello.gemstone.com/bibliocello/Pharo > > for some ideas about path names for the repositories. If you want to use a name that already exists that's not a problem, there's nothing permanent about the bibliocello site right now... Looks cool! Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. |
Re: another thought about the #stable version
|
|
In reply to this post by Dale Henrichs
Hi,
On 17 Jan 2011, at 22:21, Dale Henrichs wrote: > My point is that we can't take the #stable symbolic version _name_ too literally. Again the name is #stable, but it's real meaning is "recommended version to load for a platform". For platform versions that are stable then the #stable version of a project is expected to be #stable. For unstable platform versions all bets are off. > ... > So if I were to follow the meaning of stable too strictly I can't claim that Metacello is stable on Pharo1.2. But I am declaring that 1.0-beta.28 is the version to use on Pharo1.2 and if it happens to break then put that down to the instability of the platform version not the literal meaning of stable. > ... > In the end I think that it is important that every developer define the #stable version of his project for the platforms that he is supporting the product on ... Wouldn't 'default' describe this situation more appropriately? :) Cheers, Doru > > Dale > > On 01/17/2011 12:19 PM, Mariano Martinez Peck wrote: >> >> >> On Mon, Jan 17, 2011 at 7:10 PM, Dale <[hidden email] >> <mailto:[hidden email]>> wrote: >> >> As I am getting close to pushing symbolic versions out the door, I >> thought it was worth sharing another thought on the #stable >> version ... The thought is that when talking about a stable version >> for Pharo1.2 or Pharo1.3 coming up. I think that it should be valid to >> define the stable version for a platform version that is under >> development as #development. >> >> So the following should be used for the Pharo1.2 versions of projects >> until the platform and the project has settled down: >> >> stable: spec >> <symbolicVersion: #'stable'> >> spec for: #'pharo1.0.x' version: '1.1.3'. >> spec for: #'pharo1.1.x' version: '1.1.5'. >> spec for: #'pharo1.2.x' version: #development. >> >> >> I agree at some point. >> I agree and I like the idea that Metacello let me use ANOTHER >> symbolic/literal version inside another symbolic version, like in this >> case with the #development >> >> However, and this is only from my point of view, putting #development as >> stable may not be correct. I mean, when you use #development, it is >> that, it is in development -> probably unustable. >> So......FROM MY POINT OF VIEW, #stable needs to ALWAYS be stalbe or >> throw an error. >> >> If I maintain SqueakDBX and even if there is a #development version, I >> wouldn't put such as stable in Pharo 1.2, I would throw an error instead >> saying there is not yet a stable version, but that you may try to use >> the latestVersion for example. So I would like to do: >> >> stable: spec >> <symbolicVersion: #'stable'> >> spec for: #'pharo1.0.x' version: '1.1.3'. >> spec for: #'pharo1.1.x' version: '1.1.5'. >> spec for: #'pharo1.2.x' do: [ Error signal: 'There is no stable >> version for Pharo 1.2. You may want to try blah... blah..' ]. >> >> Now, of course, there can be projects where each commit is considered >> stable (even if I don't believe on them). >> >> cheers >> >> mariano >> >> >> >> For unstable platform versions, we still need to nominate a version >> that is "stable" relative to the platform version and for man >> yprojects relative to Pharo1.2 #development might be the best answer >> as constant updates may be needed as the Pharo1.2 itself moves "out >> from under" a functional release. >> >> Note that a #stable version should only be specified if there is an >> effort to port the project to Pharo1.2 and if the best answer for the >> "stable" version is #development then that is much better than no >> version. >> >> Dale >> >> > -- www.tudorgirba.com "Relationships are of two kinds: those we choose and those that happen. They both matter." |
Re: another thought about the #stable version
|
|
Perhaps, but the meaning of #stable doesn't match the Moose meaning of
'default', which is the development version to be loaded, not the production version to be loaded. This reminds me of the discussion about the meaning of the word 'free' as in beer or 'free' as in 'speech'. So the meaning of 'stable' for me is 'stable' as in boat and for Mariano it is 'stable' as in bedrock:) Again ... at this point in time I think that we need to agree on the concept rather than the name ... we can hit a thesaurus for a better name if and when we agree on a concept.... So does the concept make sense or are you actually thinking about the Moose definition of 'default'? Dale On 01/17/2011 04:17 PM, Tudor Girba wrote: > Hi, > > On 17 Jan 2011, at 22:21, Dale Henrichs wrote: > >> My point is that we can't take the #stable symbolic version _name_ too literally. Again the name is #stable, but it's real meaning is "recommended version to load for a platform". For platform versions that are stable then the #stable version of a project is expected to be #stable. For unstable platform versions all bets are off. >> ... >> So if I were to follow the meaning of stable too strictly I can't claim that Metacello is stable on Pharo1.2. But I am declaring that 1.0-beta.28 is the version to use on Pharo1.2 and if it happens to break then put that down to the instability of the platform version not the literal meaning of stable. >> ... >> In the end I think that it is important that every developer define the #stable version of his project for the platforms that he is supporting the product on ... > > Wouldn't 'default' describe this situation more appropriately? :) > > Cheers, > Doru > > > >> >> Dale >> >> On 01/17/2011 12:19 PM, Mariano Martinez Peck wrote: >>> >>> >>> On Mon, Jan 17, 2011 at 7:10 PM, Dale<[hidden email] >>> <mailto:[hidden email]>> wrote: >>> >>> As I am getting close to pushing symbolic versions out the door, I >>> thought it was worth sharing another thought on the #stable >>> version ... The thought is that when talking about a stable version >>> for Pharo1.2 or Pharo1.3 coming up. I think that it should be valid to >>> define the stable version for a platform version that is under >>> development as #development. >>> >>> So the following should be used for the Pharo1.2 versions of projects >>> until the platform and the project has settled down: >>> >>> stable: spec >>> <symbolicVersion: #'stable'> >>> spec for: #'pharo1.0.x' version: '1.1.3'. >>> spec for: #'pharo1.1.x' version: '1.1.5'. >>> spec for: #'pharo1.2.x' version: #development. >>> >>> >>> I agree at some point. >>> I agree and I like the idea that Metacello let me use ANOTHER >>> symbolic/literal version inside another symbolic version, like in this >>> case with the #development >>> >>> However, and this is only from my point of view, putting #development as >>> stable may not be correct. I mean, when you use #development, it is >>> that, it is in development -> probably unustable. >>> So......FROM MY POINT OF VIEW, #stable needs to ALWAYS be stalbe or >>> throw an error. >>> >>> If I maintain SqueakDBX and even if there is a #development version, I >>> wouldn't put such as stable in Pharo 1.2, I would throw an error instead >>> saying there is not yet a stable version, but that you may try to use >>> the latestVersion for example. So I would like to do: >>> >>> stable: spec >>> <symbolicVersion: #'stable'> >>> spec for: #'pharo1.0.x' version: '1.1.3'. >>> spec for: #'pharo1.1.x' version: '1.1.5'. >>> spec for: #'pharo1.2.x' do: [ Error signal: 'There is no stable >>> version for Pharo 1.2. You may want to try blah... blah..' ]. >>> >>> Now, of course, there can be projects where each commit is considered >>> stable (even if I don't believe on them). >>> >>> cheers >>> >>> mariano >>> >>> >>> >>> For unstable platform versions, we still need to nominate a version >>> that is "stable" relative to the platform version and for man >>> yprojects relative to Pharo1.2 #development might be the best answer >>> as constant updates may be needed as the Pharo1.2 itself moves "out >>> from under" a functional release. >>> >>> Note that a #stable version should only be specified if there is an >>> effort to port the project to Pharo1.2 and if the best answer for the >>> "stable" version is #development then that is much better than no >>> version. >>> >>> Dale >>> >>> >> > > -- > www.tudorgirba.com > > "Relationships are of two kinds: those we choose and those that happen. They both matter." > > > > > |
Re: another thought about the #stable version
|
|
In reply to this post by Tudor Girba
doru
development conveys that something is changing more than default. Stef On Jan 18, 2011, at 1:17 AM, Tudor Girba wrote: > Hi, > > On 17 Jan 2011, at 22:21, Dale Henrichs wrote: > >> My point is that we can't take the #stable symbolic version _name_ too literally. Again the name is #stable, but it's real meaning is "recommended version to load for a platform". For platform versions that are stable then the #stable version of a project is expected to be #stable. For unstable platform versions all bets are off. >> ... >> So if I were to follow the meaning of stable too strictly I can't claim that Metacello is stable on Pharo1.2. But I am declaring that 1.0-beta.28 is the version to use on Pharo1.2 and if it happens to break then put that down to the instability of the platform version not the literal meaning of stable. >> ... >> In the end I think that it is important that every developer define the #stable version of his project for the platforms that he is supporting the product on ... > > Wouldn't 'default' describe this situation more appropriately? :) > > Cheers, > Doru > > > >> >> Dale >> >> On 01/17/2011 12:19 PM, Mariano Martinez Peck wrote: >>> >>> >>> On Mon, Jan 17, 2011 at 7:10 PM, Dale <[hidden email] >>> <mailto:[hidden email]>> wrote: >>> >>> As I am getting close to pushing symbolic versions out the door, I >>> thought it was worth sharing another thought on the #stable >>> version ... The thought is that when talking about a stable version >>> for Pharo1.2 or Pharo1.3 coming up. I think that it should be valid to >>> define the stable version for a platform version that is under >>> development as #development. >>> >>> So the following should be used for the Pharo1.2 versions of projects >>> until the platform and the project has settled down: >>> >>> stable: spec >>> <symbolicVersion: #'stable'> >>> spec for: #'pharo1.0.x' version: '1.1.3'. >>> spec for: #'pharo1.1.x' version: '1.1.5'. >>> spec for: #'pharo1.2.x' version: #development. >>> >>> >>> I agree at some point. >>> I agree and I like the idea that Metacello let me use ANOTHER >>> symbolic/literal version inside another symbolic version, like in this >>> case with the #development >>> >>> However, and this is only from my point of view, putting #development as >>> stable may not be correct. I mean, when you use #development, it is >>> that, it is in development -> probably unustable. >>> So......FROM MY POINT OF VIEW, #stable needs to ALWAYS be stalbe or >>> throw an error. >>> >>> If I maintain SqueakDBX and even if there is a #development version, I >>> wouldn't put such as stable in Pharo 1.2, I would throw an error instead >>> saying there is not yet a stable version, but that you may try to use >>> the latestVersion for example. So I would like to do: >>> >>> stable: spec >>> <symbolicVersion: #'stable'> >>> spec for: #'pharo1.0.x' version: '1.1.3'. >>> spec for: #'pharo1.1.x' version: '1.1.5'. >>> spec for: #'pharo1.2.x' do: [ Error signal: 'There is no stable >>> version for Pharo 1.2. You may want to try blah... blah..' ]. >>> >>> Now, of course, there can be projects where each commit is considered >>> stable (even if I don't believe on them). >>> >>> cheers >>> >>> mariano >>> >>> >>> >>> For unstable platform versions, we still need to nominate a version >>> that is "stable" relative to the platform version and for man >>> yprojects relative to Pharo1.2 #development might be the best answer >>> as constant updates may be needed as the Pharo1.2 itself moves "out >>> from under" a functional release. >>> >>> Note that a #stable version should only be specified if there is an >>> effort to port the project to Pharo1.2 and if the best answer for the >>> "stable" version is #development then that is much better than no >>> version. >>> >>> Dale >>> >>> >> > > -- > www.tudorgirba.com > > "Relationships are of two kinds: those we choose and those that happen. They both matter." > > > > > |
Re: another thought about the #stable version
|
|
Hi,
I just pointed out that you were basically saying that "stable" is not really stable, especially when moving from one Pharo version to another, but that it should provide the best approximation for what should be loaded without much thinking. So, given that you actually want to point to what people should load when not knowing much about the project, perhaps 'default' is a more appropriate name. And like you said, what exactly that default version will load is dependent on the project. But, stable is just fine, too. It was more of a joke ... a bad one, it seems :). In any case, I am looking forward to using this mechanism. Cheers, Doru On 18 Jan 2011, at 09:05, stephane ducasse wrote: > doru > > development conveys that something is changing more than default. > > Stef > > On Jan 18, 2011, at 1:17 AM, Tudor Girba wrote: > >> Hi, >> >> On 17 Jan 2011, at 22:21, Dale Henrichs wrote: >> >>> My point is that we can't take the #stable symbolic version _name_ too literally. Again the name is #stable, but it's real meaning is "recommended version to load for a platform". For platform versions that are stable then the #stable version of a project is expected to be #stable. For unstable platform versions all bets are off. >>> ... >>> So if I were to follow the meaning of stable too strictly I can't claim that Metacello is stable on Pharo1.2. But I am declaring that 1.0-beta.28 is the version to use on Pharo1.2 and if it happens to break then put that down to the instability of the platform version not the literal meaning of stable. >>> ... >>> In the end I think that it is important that every developer define the #stable version of his project for the platforms that he is supporting the product on ... >> >> Wouldn't 'default' describe this situation more appropriately? :) >> >> Cheers, >> Doru >> >> >> >>> >>> Dale >>> >>> On 01/17/2011 12:19 PM, Mariano Martinez Peck wrote: >>>> >>>> >>>> On Mon, Jan 17, 2011 at 7:10 PM, Dale <[hidden email] >>>> <mailto:[hidden email]>> wrote: >>>> >>>> As I am getting close to pushing symbolic versions out the door, I >>>> thought it was worth sharing another thought on the #stable >>>> version ... The thought is that when talking about a stable version >>>> for Pharo1.2 or Pharo1.3 coming up. I think that it should be valid to >>>> define the stable version for a platform version that is under >>>> development as #development. >>>> >>>> So the following should be used for the Pharo1.2 versions of projects >>>> until the platform and the project has settled down: >>>> >>>> stable: spec >>>> <symbolicVersion: #'stable'> >>>> spec for: #'pharo1.0.x' version: '1.1.3'. >>>> spec for: #'pharo1.1.x' version: '1.1.5'. >>>> spec for: #'pharo1.2.x' version: #development. >>>> >>>> >>>> I agree at some point. >>>> I agree and I like the idea that Metacello let me use ANOTHER >>>> symbolic/literal version inside another symbolic version, like in this >>>> case with the #development >>>> >>>> However, and this is only from my point of view, putting #development as >>>> stable may not be correct. I mean, when you use #development, it is >>>> that, it is in development -> probably unustable. >>>> So......FROM MY POINT OF VIEW, #stable needs to ALWAYS be stalbe or >>>> throw an error. >>>> >>>> If I maintain SqueakDBX and even if there is a #development version, I >>>> wouldn't put such as stable in Pharo 1.2, I would throw an error instead >>>> saying there is not yet a stable version, but that you may try to use >>>> the latestVersion for example. So I would like to do: >>>> >>>> stable: spec >>>> <symbolicVersion: #'stable'> >>>> spec for: #'pharo1.0.x' version: '1.1.3'. >>>> spec for: #'pharo1.1.x' version: '1.1.5'. >>>> spec for: #'pharo1.2.x' do: [ Error signal: 'There is no stable >>>> version for Pharo 1.2. You may want to try blah... blah..' ]. >>>> >>>> Now, of course, there can be projects where each commit is considered >>>> stable (even if I don't believe on them). >>>> >>>> cheers >>>> >>>> mariano >>>> >>>> >>>> >>>> For unstable platform versions, we still need to nominate a version >>>> that is "stable" relative to the platform version and for man >>>> yprojects relative to Pharo1.2 #development might be the best answer >>>> as constant updates may be needed as the Pharo1.2 itself moves "out >>>> from under" a functional release. >>>> >>>> Note that a #stable version should only be specified if there is an >>>> effort to port the project to Pharo1.2 and if the best answer for the >>>> "stable" version is #development then that is much better than no >>>> version. >>>> >>>> Dale >>>> >>>> >>> >> >> -- >> www.tudorgirba.com >> >> "Relationships are of two kinds: those we choose and those that happen. They both matter." >> >> >> >> >> > -- www.tudorgirba.com "Every thing should have the right to be different." |
Re: another thought about the #stable version
|
|
> Hi, > > I just pointed out that you were basically saying that "stable" is not really stable, especially when moving from one Pharo version to another, but that it should provide the best approximation for what should be loaded without much thinking. So, given that you actually want to point to what people should load when not knowing much about the project, perhaps 'default' is a more appropriate name. > > And like you said, what exactly that default version will load is dependent on the project. But, stable is just fine, too. It was more of a joke ... a bad one, it seems :). ok :) I prefer stable with bugs than default because they convey different intentions. Stef > In any case, I am looking forward to using this mechanism. > > Cheers, > Doru > > > On 18 Jan 2011, at 09:05, stephane ducasse wrote: > >> doru >> >> development conveys that something is changing more than default. >> >> Stef >> >> On Jan 18, 2011, at 1:17 AM, Tudor Girba wrote: >> >>> Hi, >>> >>> On 17 Jan 2011, at 22:21, Dale Henrichs wrote: >>> >>>> My point is that we can't take the #stable symbolic version _name_ too literally. Again the name is #stable, but it's real meaning is "recommended version to load for a platform". For platform versions that are stable then the #stable version of a project is expected to be #stable. For unstable platform versions all bets are off. >>>> ... >>>> So if I were to follow the meaning of stable too strictly I can't claim that Metacello is stable on Pharo1.2. But I am declaring that 1.0-beta.28 is the version to use on Pharo1.2 and if it happens to break then put that down to the instability of the platform version not the literal meaning of stable. >>>> ... >>>> In the end I think that it is important that every developer define the #stable version of his project for the platforms that he is supporting the product on ... >>> >>> Wouldn't 'default' describe this situation more appropriately? :) >>> >>> Cheers, >>> Doru >>> >>> >>> >>>> >>>> Dale >>>> >>>> On 01/17/2011 12:19 PM, Mariano Martinez Peck wrote: >>>>> >>>>> >>>>> On Mon, Jan 17, 2011 at 7:10 PM, Dale <[hidden email] >>>>> <mailto:[hidden email]>> wrote: >>>>> >>>>> As I am getting close to pushing symbolic versions out the door, I >>>>> thought it was worth sharing another thought on the #stable >>>>> version ... The thought is that when talking about a stable version >>>>> for Pharo1.2 or Pharo1.3 coming up. I think that it should be valid to >>>>> define the stable version for a platform version that is under >>>>> development as #development. >>>>> >>>>> So the following should be used for the Pharo1.2 versions of projects >>>>> until the platform and the project has settled down: >>>>> >>>>> stable: spec >>>>> <symbolicVersion: #'stable'> >>>>> spec for: #'pharo1.0.x' version: '1.1.3'. >>>>> spec for: #'pharo1.1.x' version: '1.1.5'. >>>>> spec for: #'pharo1.2.x' version: #development. >>>>> >>>>> >>>>> I agree at some point. >>>>> I agree and I like the idea that Metacello let me use ANOTHER >>>>> symbolic/literal version inside another symbolic version, like in this >>>>> case with the #development >>>>> >>>>> However, and this is only from my point of view, putting #development as >>>>> stable may not be correct. I mean, when you use #development, it is >>>>> that, it is in development -> probably unustable. >>>>> So......FROM MY POINT OF VIEW, #stable needs to ALWAYS be stalbe or >>>>> throw an error. >>>>> >>>>> If I maintain SqueakDBX and even if there is a #development version, I >>>>> wouldn't put such as stable in Pharo 1.2, I would throw an error instead >>>>> saying there is not yet a stable version, but that you may try to use >>>>> the latestVersion for example. So I would like to do: >>>>> >>>>> stable: spec >>>>> <symbolicVersion: #'stable'> >>>>> spec for: #'pharo1.0.x' version: '1.1.3'. >>>>> spec for: #'pharo1.1.x' version: '1.1.5'. >>>>> spec for: #'pharo1.2.x' do: [ Error signal: 'There is no stable >>>>> version for Pharo 1.2. You may want to try blah... blah..' ]. >>>>> >>>>> Now, of course, there can be projects where each commit is considered >>>>> stable (even if I don't believe on them). >>>>> >>>>> cheers >>>>> >>>>> mariano >>>>> >>>>> >>>>> >>>>> For unstable platform versions, we still need to nominate a version >>>>> that is "stable" relative to the platform version and for man >>>>> yprojects relative to Pharo1.2 #development might be the best answer >>>>> as constant updates may be needed as the Pharo1.2 itself moves "out >>>>> from under" a functional release. >>>>> >>>>> Note that a #stable version should only be specified if there is an >>>>> effort to port the project to Pharo1.2 and if the best answer for the >>>>> "stable" version is #development then that is much better than no >>>>> version. >>>>> >>>>> Dale >>>>> >>>>> >>>> >>> >>> -- >>> www.tudorgirba.com >>> >>> "Relationships are of two kinds: those we choose and those that happen. They both matter." >>> >>> >>> >>> >>> >> > > -- > www.tudorgirba.com > > "Every thing should have the right to be different." > > > |
Re: another thought about the #stable version
|
|
In reply to this post by Dale Henrichs
On Mon, Jan 17, 2011 at 10:21 PM, Dale Henrichs <[hidden email]> wrote: Mariano, ok :) I understand. Again the name is #stable, but it's real meaning is "recommended version to load for a platform". For platform versions that are stable then the #stable version of a project is expected to be #stable. For unstable platform versions all bets are off. yes, exactly, but exactly becuase of that, it was not stable. ... I think that specifying #stable as #bleedingEdge would be preferable in that case, because then the _users_ of the configuration don't have to guess or find out the special instructions for loading each project ... the rule is that if there is a #stable version defined, then that is the recommended version and if the platform itself is unstable, the everything must be taken with a grain of salt. true But I am declaring that 1.0-beta.28 is the version to use on Pharo1.2 and if it happens to break then put that down to the instability of the platform version not the literal meaning of stable. Ok, I got it. Sorry, it was my bad to misunderstood.
exactly.
|
Re: another thought about the #stable version
|
|
In reply to this post by Tudor Girba
Hey Doru,
I saw the smiley:) .... but it is hard to communicate over email. You and Mariano have absolutely valid points and concerns ... I saw a tweet the other day, that roughly said: "developers could make a perfect world if they were allowed to go back in time to change things" If I had it to do over again, I would have started this conversation months ago rather than having it now ... but I didn't know then what I know now and the conversation is important to have now... Thanks, Dale On 01/18/2011 01:21 AM, Tudor Girba wrote: > Hi, > > I just pointed out that you were basically saying that "stable" is not really stable, especially when moving from one Pharo version to another, but that it should provide the best approximation for what should be loaded without much thinking. So, given that you actually want to point to what people should load when not knowing much about the project, perhaps 'default' is a more appropriate name. > > And like you said, what exactly that default version will load is dependent on the project. But, stable is just fine, too. It was more of a joke ... a bad one, it seems :). > > In any case, I am looking forward to using this mechanism. > > Cheers, > Doru > > > On 18 Jan 2011, at 09:05, stephane ducasse wrote: > >> doru >> >> development conveys that something is changing more than default. >> >> Stef >> >> On Jan 18, 2011, at 1:17 AM, Tudor Girba wrote: >> >>> Hi, >>> >>> On 17 Jan 2011, at 22:21, Dale Henrichs wrote: >>> >>>> My point is that we can't take the #stable symbolic version _name_ too literally. Again the name is #stable, but it's real meaning is "recommended version to load for a platform". For platform versions that are stable then the #stable version of a project is expected to be #stable. For unstable platform versions all bets are off. >>>> ... >>>> So if I were to follow the meaning of stable too strictly I can't claim that Metacello is stable on Pharo1.2. But I am declaring that 1.0-beta.28 is the version to use on Pharo1.2 and if it happens to break then put that down to the instability of the platform version not the literal meaning of stable. >>>> ... >>>> In the end I think that it is important that every developer define the #stable version of his project for the platforms that he is supporting the product on ... >>> >>> Wouldn't 'default' describe this situation more appropriately? :) >>> >>> Cheers, >>> Doru >>> >>> >>> >>>> >>>> Dale >>>> >>>> On 01/17/2011 12:19 PM, Mariano Martinez Peck wrote: >>>>> >>>>> >>>>> On Mon, Jan 17, 2011 at 7:10 PM, Dale<[hidden email] >>>>> <mailto:[hidden email]>> wrote: >>>>> >>>>> As I am getting close to pushing symbolic versions out the door, I >>>>> thought it was worth sharing another thought on the #stable >>>>> version ... The thought is that when talking about a stable version >>>>> for Pharo1.2 or Pharo1.3 coming up. I think that it should be valid to >>>>> define the stable version for a platform version that is under >>>>> development as #development. >>>>> >>>>> So the following should be used for the Pharo1.2 versions of projects >>>>> until the platform and the project has settled down: >>>>> >>>>> stable: spec >>>>> <symbolicVersion: #'stable'> >>>>> spec for: #'pharo1.0.x' version: '1.1.3'. >>>>> spec for: #'pharo1.1.x' version: '1.1.5'. >>>>> spec for: #'pharo1.2.x' version: #development. >>>>> >>>>> >>>>> I agree at some point. >>>>> I agree and I like the idea that Metacello let me use ANOTHER >>>>> symbolic/literal version inside another symbolic version, like in this >>>>> case with the #development >>>>> >>>>> However, and this is only from my point of view, putting #development as >>>>> stable may not be correct. I mean, when you use #development, it is >>>>> that, it is in development -> probably unustable. >>>>> So......FROM MY POINT OF VIEW, #stable needs to ALWAYS be stalbe or >>>>> throw an error. >>>>> >>>>> If I maintain SqueakDBX and even if there is a #development version, I >>>>> wouldn't put such as stable in Pharo 1.2, I would throw an error instead >>>>> saying there is not yet a stable version, but that you may try to use >>>>> the latestVersion for example. So I would like to do: >>>>> >>>>> stable: spec >>>>> <symbolicVersion: #'stable'> >>>>> spec for: #'pharo1.0.x' version: '1.1.3'. >>>>> spec for: #'pharo1.1.x' version: '1.1.5'. >>>>> spec for: #'pharo1.2.x' do: [ Error signal: 'There is no stable >>>>> version for Pharo 1.2. You may want to try blah... blah..' ]. >>>>> >>>>> Now, of course, there can be projects where each commit is considered >>>>> stable (even if I don't believe on them). >>>>> >>>>> cheers >>>>> >>>>> mariano >>>>> >>>>> >>>>> >>>>> For unstable platform versions, we still need to nominate a version >>>>> that is "stable" relative to the platform version and for man >>>>> yprojects relative to Pharo1.2 #development might be the best answer >>>>> as constant updates may be needed as the Pharo1.2 itself moves "out >>>>> from under" a functional release. >>>>> >>>>> Note that a #stable version should only be specified if there is an >>>>> effort to port the project to Pharo1.2 and if the best answer for the >>>>> "stable" version is #development then that is much better than no >>>>> version. >>>>> >>>>> Dale >>>>> >>>>> >>>> >>> >>> -- >>> www.tudorgirba.com >>> >>> "Relationships are of two kinds: those we choose and those that happen. They both matter." >>> >>> >>> >>> >>> >> > > -- > www.tudorgirba.com > > "Every thing should have the right to be different." > > > |
Re: another thought about the #stable version
|
|
In reply to this post by Mariano Martinez Peck
Mariano,
No need to apologize. I agree with your points and understand your concerns. I didn't do a good job of communicating my thoughts ... I like to think that at this point we are in "screaming" agreement:) Having slept on the issue, I think that we can put together some simple guidelines for using symbolic versions I'll send out an email with my initial thoughts later this morning. Dale On 01/18/2011 03:07 AM, Mariano Martinez Peck wrote: > > > On Mon, Jan 17, 2011 at 10:21 PM, Dale Henrichs <[hidden email] > <mailto:[hidden email]>> wrote: > > Mariano, > > I understand your concern and I started this thread to discuss the > issue ... > > My point is that we can't take the #stable symbolic version _name_ > too literally. > > > ok :) I understand. > > Again the name is #stable, but it's real meaning is "recommended > version to load for a platform". For platform versions that are > stable then the #stable version of a project is expected to be > #stable. For unstable platform versions all bets are off. > > If you recall, not too long ago the way to get OmniBrowser to load > into Pharo1.2 was to load the latest versions of all of the packages > > > yes, exactly, but exactly becuase of that, it was not stable. > > ... I think that specifying #stable as #bleedingEdge would be > preferable in that case, because then the _users_ of the > configuration don't have to guess or find out the special > instructions for loading each project ... the rule is that if there > is a #stable version defined, then that is the recommended version > and if the platform itself is unstable, the everything must be taken > with a grain of salt. > > The next logical step is to define the #stable version as the > #development version ... one could use the literal version for a > version whose blessing is #development, but I think that more > information is conveyed by using #development and #bleedingEdge than > using '1.2.3' (which happens to be a development version) ... > > Over the weekend, I loaded and tested Metacello in the absolute > latest version of Pharo1.2beta and OmniBrowser loaded fine, but the > whole windowing system was broken (something to do with shout > problems) ... this morning I loaded Metacello into > PharoCore-1.2beta-12294 (which isn't that old) and everything loaded > fine,OB, the windowing system and OB-Metacello were functional ... > > So if I were to follow the meaning of stable too strictly I can't > claim that Metacello is stable on Pharo1.2. > > > true > > But I am declaring that 1.0-beta.28 is the version to use on > Pharo1.2 and if it happens to break then put that down to the > instability of the platform version not the literal meaning of stable. > > > Ok, I got it. Sorry, it was my bad to misunderstood. > > > I talk about one of my canoes being stable relative to another > canoe, yet canoes are inherently unstable .... > > In the end I think that it is important that every developer define > the #stable version of his project for the platforms that he is > supporting the product on ... > > > exactly. > > > For GemTools I can't consider starting a port to a new version of > Pharo until #stable versions of FFI, OB, Shout and HelpSystem show > up and when they do I'm off to the races ... my code itself will > definitely be affected by bugs that appear in the underlying > projects, but if the fix isn't in my code, my users can just load > the #stable version of GemTools (which would reference the #stable > versions of the other projects) and take advantage of the bugfixes > in other projects... > > Dale > > > On 01/17/2011 12:19 PM, Mariano Martinez Peck wrote: > > > > On Mon, Jan 17, 2011 at 7:10 PM, Dale <[hidden email] > <mailto:[hidden email]> > <mailto:[hidden email] <mailto:[hidden email]>>> wrote: > > As I am getting close to pushing symbolic versions out the > door, I > thought it was worth sharing another thought on the #stable > version ... The thought is that when talking about a stable > version > for Pharo1.2 or Pharo1.3 coming up. I think that it should > be valid to > define the stable version for a platform version that is under > development as #development. > > So the following should be used for the Pharo1.2 versions of > projects > until the platform and the project has settled down: > > stable: spec > <symbolicVersion: #'stable'> > spec for: #'pharo1.0.x' version: '1.1.3'. > spec for: #'pharo1.1.x' version: '1.1.5'. > spec for: #'pharo1.2.x' version: #development. > > > I agree at some point. > I agree and I like the idea that Metacello let me use ANOTHER > symbolic/literal version inside another symbolic version, like > in this > case with the #development > > However, and this is only from my point of view, putting > #development as > stable may not be correct. I mean, when you use #development, it is > that, it is in development -> probably unustable. > So......FROM MY POINT OF VIEW, #stable needs to ALWAYS be stalbe or > throw an error. > > If I maintain SqueakDBX and even if there is a #development > version, I > wouldn't put such as stable in Pharo 1.2, I would throw an error > instead > saying there is not yet a stable version, but that you may try > to use > the latestVersion for example. So I would like to do: > > stable: spec > <symbolicVersion: #'stable'> > spec for: #'pharo1.0.x' version: '1.1.3'. > spec for: #'pharo1.1.x' version: '1.1.5'. > spec for: #'pharo1.2.x' do: [ Error signal: 'There is no stable > version for Pharo 1.2. You may want to try blah... blah..' ]. > > Now, of course, there can be projects where each commit is > considered > stable (even if I don't believe on them). > > cheers > > mariano > > > > For unstable platform versions, we still need to nominate a > version > that is "stable" relative to the platform version and for man > yprojects relative to Pharo1.2 #development might be the > best answer > as constant updates may be needed as the Pharo1.2 itself > moves "out > from under" a functional release. > > Note that a #stable version should only be specified if > there is an > effort to port the project to Pharo1.2 and if the best > answer for the > "stable" version is #development then that is much better than no > version. > > Dale > > > > |
«
Return to Metacello
|
1 view|%1 views
| Free forum by Nabble | Edit this page |