symbolic versions
Locked
12
12
 
|
Hi,
I think I did not understand :). I suggest to make a distinction in vocabulary to get communication clearer: - projectVersion: the version of the overall project (e.g., Seaside). This corresponds to either a baseline or a version method in the ConfigurationOfXXX - packageVersion: the version of a package in Monticello (e.g., Moose-Core) Cheers, Doru On 4 Oct 2010, at 22:04, Dale Henrichs wrote: > > > Mariano Martinez Peck wrote: >> On Mon, Oct 4, 2010 at 9:04 PM, Dale Henrichs <[hidden email] <mailto:[hidden email]>> wrote: >> Mariano, >> Yes I think you are right that #stableVersion should be used 99% of >> the time ... but that's when I think that #'3.0' and #'3.1' style >> stableVersions will become useful ... #stableVersion will stick on >> the 3.0 branch until 3.1 is released and then #stable version will >> track the 3.1 branch ... however, there may be folks that will >> continue using the 3.0 branch in which case a #'3.0' symbolic >> version will be useful ... >> The nice thing is that the symbolic versions are platform-specific, >> so in the above case the #stableVersion for Pharo1.0 might stay on >> the 3.0 branch even when the stableVersion moves on to 3.1 for other >> versions of Pharo. >> Thinking back in the past ... I had versions of GemTools that were >> very sensitive to the version of OmniBrowser that was being used (in >> the old world using the package universe, that meant that all of a >> sudden the GemTools target would start loading a version of >> OmniBrowser that was incompatible...) which means that in some more >> obscure cases specific versions will still be used. >> Thanks Dale. I got it. Now...I have a question...what will happen in the case there you DO NOT specify a version to a project reference? or even more, when you load a baseline? >> Right now you take the latest version when a version was not specified....will that remain like that or now it will try to load stableVersion instead? >> cheers >> Mariano > > Not sure. > > Without a default definition of #stableVersion I don't think that we can default to using the #stableVersion as a default in a project specification.... > > #bleedingEdgeVersion probably makes a little more sense as a default (there is a "well understood" default definition of #bleedingEdge), however, #bleedingEdge would be a surprise/change in the behavior ... > > We have a couple of options I think... > > 1. _require_ that a version be specified in the projectReference with > a "grace period" for latestVersion ... the default remains > #latestVersion, but at 1.0 the validator flags missing version > specs as an error and soon we deprecate #latestVersion, so > eventually the configs stop working, but there should have been > plenty of noise leading to that point... > 2. define a default for #stableVersion and use #stableVersion as the > default > 3. change the default to #bleedingEdgeVersion and live with the > ensuing chaos (if any) > 4. use #stableVersion as the default and let the ensuing errors point > out the configurations that are missing a #stableVersion > specification > > I think that I like the idea of no defaults for versions ... symbolicVersions provide enough flexibility (I think) that we can get away with no defaults. > > With that said, I think that in a perfect world, #bleedingEdgeVersion will be used in 100% of the #baseline project reference versions and #stableVersion will be used in 99% of project references for #versions. Which points towards option 4.... > > Dale > -- www.tudorgirba.com "In a world where everything is moving ever faster, one might have better chances to win by moving slower." |
|
|
In reply to this post by Dale Henrichs
On Mon, Oct 4, 2010 at 10:04 PM, Dale Henrichs <[hidden email]> wrote:
Noooo :) 3. change the default to #bleedingEdgeVersion and live with the Noooo :) 4. use #stableVersion as the default and let the ensuing errors point I think I would like not to have default here or option 4). Of course, if there is no default, there must be a validation and throw a clear error message so that a developer can notice that he didn't put any version in the project reference.
mmmmm #baseline project references? what is this? versions and #stableVersion will be used in 99% of project references for #versions. Which points towards option 4.... Yep. I am confused about which one I prefer...if no default or #stableVersion
|
|
|
On 10/08/2010 09:39 AM, Mariano Martinez Peck wrote:
> > > On Mon, Oct 4, 2010 at 10:04 PM, Dale Henrichs <[hidden email] > <mailto:[hidden email]>> wrote: > > > > Mariano Martinez Peck wrote: > > > > On Mon, Oct 4, 2010 at 9:04 PM, Dale Henrichs > <[hidden email] <mailto:[hidden email]> > <mailto:[hidden email] <mailto:[hidden email]>>> wrote: > > Mariano, > > Yes I think you are right that #stableVersion should be used > 99% of > the time ... but that's when I think that #'3.0' and #'3.1' > style > stableVersions will become useful ... #stableVersion will > stick on > the 3.0 branch until 3.1 is released and then #stable > version will > track the 3.1 branch ... however, there may be folks that will > continue using the 3.0 branch in which case a #'3.0' symbolic > version will be useful ... > > The nice thing is that the symbolic versions are > platform-specific, > so in the above case the #stableVersion for Pharo1.0 might > stay on > the 3.0 branch even when the stableVersion moves on to 3.1 > for other > versions of Pharo. > > Thinking back in the past ... I had versions of GemTools > that were > very sensitive to the version of OmniBrowser that was being > used (in > the old world using the package universe, that meant that > all of a > sudden the GemTools target would start loading a version of > OmniBrowser that was incompatible...) which means that in > some more > obscure cases specific versions will still be used. > > > Thanks Dale. I got it. Now...I have a question...what will > happen in the case there you DO NOT specify a version to a > project reference? or even more, when you load a baseline? > > Right now you take the latest version when a version was not > specified....will that remain like that or now it will try to > load stableVersion instead? > > cheers > > Mariano > > > Not sure. > > Without a default definition of #stableVersion I don't think that we > can default to using the #stableVersion as a default in a project > specification.... > > #bleedingEdgeVersion probably makes a little more sense as a default > (there is a "well understood" default definition of #bleedingEdge), > however, #bleedingEdge would be a surprise/change in the behavior ... > > We have a couple of options I think... > > 1. _require_ that a version be specified in the projectReference with > a "grace period" for latestVersion ... the default remains > #latestVersion, but at 1.0 the validator flags missing version > specs as an error and soon we deprecate #latestVersion, so > eventually the configs stop working, but there should have been > plenty of noise leading to that point... > 2. define a default for #stableVersion and use #stableVersion as the > default > > > Noooo :) > > 3. change the default to #bleedingEdgeVersion and live with the > ensuing chaos (if any) > > > > Noooo :) > > 4. use #stableVersion as the default and let the ensuing errors point > out the configurations that are missing a #stableVersion > specification > > I think that I like the idea of no defaults for versions ... > symbolicVersions provide enough flexibility (I think) that we can > get away with no defaults. > > > I think I would like not to have default here or option 4). Of course, > if there is no default, there must be a validation and throw a clear > error message so that a developer can notice that he didn't put any > version in the project reference. > > > With that said, I think that in a perfect world, > #bleedingEdgeVersion will be used in 100% of the #baseline project > reference > > > mmmmm #baseline project references? what is this? In a #baseline when you define a project reference, you can specify a project version. Today in the Seaside 3.0 config I do something like the following: spec project: 'Grease Core' with: [ spec className: 'ConfigurationOfGrease'; versionString: '1.0-alpha9.3-baseline'; loads: #('Core' ); repository: 'http://www.squeaksource.com/MetacelloRepository' ]. doing this will propogate the loading of the latest packages to other projects as well ... which is what we are trying to accomplish with the #bleedingEge version. With the #bleedingEdgeVersion I would tend to do this instead: spec project: 'Grease Core' with: [ spec className: 'ConfigurationOfGrease'; versionString: #bleedingEdge; loads: #('Core' ); repository: 'http://www.squeaksource.com/MetacelloRepository' ]. and avoid a reference to an explicit version string ... BTW, I would think that Doru would use this approach as well in defining his 'default' version. > > versions and #stableVersion will be used in 99% of project > references for #versions. Which points towards option 4.... > > > Yep. > > I am confused about which one I prefer...if no default or #stableVersion I think that for #baseline versions, #bleedingEdge is the right answer for the default, but once the #baseline is imported into a #version, then #bleedingEgde isn't correct (as a default)... At this point I would say let's go with no default and _require_ an explicit version specification. With symbolicVersions basically allow the developer to choose the default behavior and then it is explicit an noone needs to know whtat the default is... Dale |
|
|
I would put that in a version method, not baseline. But anyway, I understood now. I've never put a versionString in baselines so far, maybe that's why I didn't understand.
Ok
|
|
|
On 10/10/2010 02:48 AM, Mariano Martinez Peck wrote:
> > > mmmmm #baseline project references? what is this? > > > In a #baseline when you define a project reference, you can specify > a project version. Today in the Seaside 3.0 config I do something > like the following: > > spec > project: 'Grease Core' with: [ > spec > className: 'ConfigurationOfGrease'; > versionString: '1.0-alpha9.3-baseline'; > loads: #('Core' ); > repository: 'http://www.squeaksource.com/MetacelloRepository' ]. > > doing this will propogate the loading of the latest packages to > other projects as well ... which is what we are trying to accomplish > with the #bleedingEge version. With the #bleedingEdgeVersion I would > tend to do this instead: > > spec > project: 'Grease Core' with: [ > spec > className: 'ConfigurationOfGrease'; > versionString: #bleedingEdge; > loads: #('Core' ); > repository: 'http://www.squeaksource.com/MetacelloRepository' ]. > > and avoid a reference to an explicit version string ... BTW, I > would think that Doru would use this approach as well in defining > his 'default' version. > > > > I would put that in a version method, not baseline. But anyway, I > understood now. I've never put a versionString in baselines so far, > maybe that's why I didn't understand. I use a #versionString in baseline project references to _propogate_ the loading of latest versions .... For example it means that with ConfigurationOfSeaside30, I can load the latest baseline version and get the latest code loaded for Grease, etc... Dale |
«
Return to Metacello
|
1 view|%1 views
| Free forum by Nabble | Edit this page |