Probably Metacello sucksâ¦
Hi, this is an observation on usage of Metacello. I guess that metacello is too complicated to be used. For example I was using the `jenkins` version of Woden configuration, but now itâs broken. And when you look at the Woden repo[1] it says that the way to load it is: Gofer new smalltalkhubUser: 'PharoExtras' project: 'NBOpenGL'; package: 'ConfigurationOfNBOpenGL'; load. ((Smalltalk at: #ConfigurationOfNBOpenGL) project version: '3.0') load. Gofer new smalltalkhubUser: 'Pharo' project: 'OSWindow'; package: 'ConfigurationOfOSWindow'; load. (Smalltalk at: #ConfigurationOfOSWindow) loadBleedingEdge. Gofer new smalltalkhubUser: 'ronsaldo' project: 'Woden'; package: 'ConfigurationOfWoden'; load. (Smalltalk at: #ConfigurationOfWoden) loadBleedingEdge Maybe instead of depending on the configuration of Woden, and saying that to load my project, people should just use a stable version of my configuration, I should copy the script from Woden repo, add some more lines to load the other projects I depend on and ask people to run a half page script in order to use my tools? What do you think? it looks like an easier solution. Uko [1]: http://smalltalkhub.com/#!/~ronsaldo/Woden
Hi,
this is an observation on usage of Metacello. I guess that metacello is too complicated to be used. For example I was using the `jenkins` version of Woden configuration, but now itâs broken.
How?
And when you look at the Woden repo[1] it says that the way to load it is:
Gofer new smalltalkhubUser: 'PharoExtras' project: 'NBOpenGL'; package: 'ConfigurationOfNBOpenGL'; load. ((Smalltalk at: #ConfigurationOfNBOpenGL) project version: '3.0') load. Gofer new smalltalkhubUser: 'Pharo' project: 'OSWindow'; package: 'ConfigurationOfOSWindow'; load. (Smalltalk at: #ConfigurationOfOSWindow) loadBleedingEdge. Gofer new smalltalkhubUser: 'ronsaldo' project: 'Woden'; package: 'ConfigurationOfWoden'; load. (Smalltalk at: #ConfigurationOfWoden) loadBleedingEdge
Maybe instead of depending on the configuration of Woden, and saying that to load my project, people should just use a stable version of my configuration, I should copy the script from Woden repo, add some more lines to load the other projects I depend on and ask people to run a half page script in order to use my tools?
What do you think? it looks like an easier solution.
I do not understand your problem. I know that jb produced a new configuration for Woden. And it should work. Every project should have a configuration. Stef
On 31 May 2015, at 13:29, stepharo <stepharo@free.fr> wrote:
Hi,
this is an observation on usage of Metacello. I guess that metacello is too complicated to be used. For example I was using the `jenkins` version of Woden configuration, but now itâs broken.
How?
And when you look at the Woden repo[1] it says that the way to load it is:
Gofer new smalltalkhubUser: 'PharoExtras' project: 'NBOpenGL'; package: 'ConfigurationOfNBOpenGL'; load. ((Smalltalk at: #ConfigurationOfNBOpenGL) project version: '3.0') load. Gofer new smalltalkhubUser: 'Pharo' project: 'OSWindow'; package: 'ConfigurationOfOSWindow'; load. (Smalltalk at: #ConfigurationOfOSWindow) loadBleedingEdge. Gofer new smalltalkhubUser: 'ronsaldo' project: 'Woden'; package: 'ConfigurationOfWoden'; load. (Smalltalk at: #ConfigurationOfWoden) loadBleedingEdge
Maybe instead of depending on the configuration of Woden, and saying that to load my project, people should just use a stable version of my configuration, I should copy the script from Woden repo, add some more lines to load the other projects I depend on and ask people to run a half page script in order to use my tools?
What do you think? it looks like an easier solution.
I do not understand your problem. I know that jb produced a new configuration for Woden. And it should work.
But it doesnât ;). The script loads everything, while the configuration says: "Error: Name not found: WithOpenGLAndExamplesâ.
Every project should have a configuration.
But it should be a responsibility of the owner, not JBâ¦
Stef
On 31/05/2015 13:34, Yuriy Tymchuk wrote:
On 31 May 2015, at 13:29, stepharo <stepharo@free.fr <mailto:stepharo@free.fr>> wrote:
Hi,
this is an observation on usage of Metacello. I guess that metacello is too complicated to be used. For example I was using the `jenkins` version of Woden configuration, but now itâs broken.
How?
And when you look at the Woden repo[1] it says that the way to load it is:
Gofer new smalltalkhubUser: 'PharoExtras' project: 'NBOpenGL'; package: 'ConfigurationOfNBOpenGL'; load. ((Smalltalk at: #ConfigurationOfNBOpenGL) project version: '3.0') load. Gofer new smalltalkhubUser: 'Pharo' project: 'OSWindow'; package: 'ConfigurationOfOSWindow'; load. (Smalltalk at: #ConfigurationOfOSWindow) loadBleedingEdge. Gofer new smalltalkhubUser: 'ronsaldo' project: 'Woden'; package: 'ConfigurationOfWoden'; load. (Smalltalk at: #ConfigurationOfWoden) loadBleedingEdge
Maybe instead of depending on the configuration of Woden, and saying that to load my project, people should just use a stable version of my configuration, I should copy the script from Woden repo, add some more lines to load the other projects I depend on and ask people to run a half page script in order to use my tools?
What do you think? it looks like an easier solution.
I do not understand your problem. I know that jb produced a new configuration for Woden. And it should work.
But it doesnât ;). The script loads everything, while the configuration says: "Error: Name not found: WithOpenGLAndExamplesâ.
It's not broken it's just a bug related to configuration present by default in the image, you have to unload the oswindow configuration first... MCPackageLoader unloadPackage: (MCPackage named: 'ConfigurationOfOSWindow')
Every project should have a configuration.
But it should be a responsibility of the owner, not JBâ¦
Stef
It is not going to get much easier than Metacello. Referring to #stable should probably stop, at least for configurations that are being developed or use dependencies that are being developed. And we need better tool support for groups. Configuration Management is never going to be easy. The Woden script looks broken, it depends on a numbered version of a dependency. Stable version of NBOpenGL is 3.1, not 3.0 That depends on version 3.0 of NBXLib NBXLib defines no symbolic versions OSWindow stable refers to NBXLib-Core-RonieSalgado.13 that doesn't exist in PharoExtras/NBOpenGL Looks like a good moment to draw some dependency diagrams Stephan
Once Stef mentioned that there is some project for dependency checking. What was it? Maybe we can use that? Uko
On 31 May 2015, at 19:42, Stephan Eggermont <stephan@stack.nl> wrote:
It is not going to get much easier than Metacello. Referring to #stable should probably stop, at least for configurations that are being developed or use dependencies that are being developed. And we need better tool support for groups. Configuration Management is never going to be easy.
The Woden script looks broken, it depends on a numbered version of a dependency.
Stable version of NBOpenGL is 3.1, not 3.0 That depends on version 3.0 of NBXLib NBXLib defines no symbolic versions OSWindow stable refers to NBXLib-Core-RonieSalgado.13 that doesn't exist in PharoExtras/NBOpenGL
Looks like a good moment to draw some dependency diagrams
Stephan
Le 11 juin 2015 à 07:52, Yuriy Tymchuk a écrit :
Once Stef mentioned that there is some project for dependency checking. What was it? Maybe we can use that?
http://smalltalkhub.com/#!/~PharoExtras/Tool-DependencyAnalyser But take care, it only spots static dependencies (inheritance, reference, extensions, traits).
On 11/06/15 07:52, Yuriy Tymchuk wrote:
Once Stef mentioned that there is some project for dependency checking. What was it? Maybe we can use that?
What I've done is get all latest versions out of smalltalkhub and collect the signatures that are used. That can provide upper and lower limits of possible versions. Stephan
Absence of Metacello won't help you dealing with dependencies and loading stuff by using hand-made scripts by dozens of people written at different points in time and not maintained by anyone. It may be too complicated to use, especially at earlier stages of development, and in situations, when all you need is to use latest versions of everything available (aka #bleedingedge). But always staying on bleeding edge hurts a lot (that's why it called so) and it is conscious choice of many professional developers to base own development on latest but stable versions of dependencies. Simply because then you have more time focusing on what you want to do, instead of fighting with various bugs and drastic changes and updates in numerous dependencies. And this is where tools like Metacello helping a lot. Because once you define stable point, you can always be sure that you can reproduce it at any moment and load without problems. And no, script on which you spent 1 minute and placed on pastebin doesn't helps in such situation. It just contributes even more mess to what is already there. -- Best regards, Igor Stasenko.
dependency management for projects is *never* an easy task. who think that the complex on loading project X or Y is because of metacello simply does not understand the inherent complexity the task it tries to solve has. things can be improved, yes⦠but no matter what tools we create, this will just make a bit easier what is complex. now⦠I think one of our problems is the use of #stable into configurations. I have expressed my concerns other moments, but here it is again: Project A uses for instance Seaside stable which is, when Project A starts Seaside 3.0 time after owner tries to load Project A⦠but since then stable from Seaside has move from Seaside 3.0, to 3.1.2 now⦠that can be ânot desiredâ at all. Project A wanted Seaside 3.0, not 3.1 (of course, if using Semantic Versioning that will mean there is just changes to the API in a compatible way⦠but we all know we do not use semver correctly almost never). So⦠in fact Project A cannot depend on Seaside/#stable⦠instead, he should depend on Seaside/3.0 directly to be sure you have the version you want. that of course introduces other kind of problems, like: what happens if I want to install Project A who depends on Seaside/3.0 and Project B who depends on Seaside/3.0.2 Well⦠ideally, we need to be able to resolve those problems when loading. Also, it would be cool to specify version dependencies as âSeaside/3.*â, for instance⦠but well⦠thatâs another thread :) As you can see⦠is not an easy task. Esteban
On 12 Jun 2015, at 02:28, Igor Stasenko <siguctua@gmail.com> wrote:
Absence of Metacello won't help you dealing with dependencies and loading stuff by using hand-made scripts by dozens of people written at different points in time and not maintained by anyone.
It may be too complicated to use, especially at earlier stages of development, and in situations, when all you need is to use latest versions of everything available (aka #bleedingedge).
But always staying on bleeding edge hurts a lot (that's why it called so) and it is conscious choice of many professional developers to base own development on latest but stable versions of dependencies. Simply because then you have more time focusing on what you want to do, instead of fighting with various bugs and drastic changes and updates in numerous dependencies. And this is where tools like Metacello helping a lot. Because once you define stable point, you can always be sure that you can reproduce it at any moment and load without problems. And no, script on which you spent 1 minute and placed on pastebin doesn't helps in such situation. It just contributes even more mess to what is already there.
-- Best regards, Igor Stasenko.
On 12-06-15 09:34, Esteban Lorenzano wrote:
Project A uses for instance Seaside stable which is, when Project A starts Seaside 3.0 time after owner tries to load Project A⦠but since then stable from Seaside has move from Seaside 3.0, to 3.1.2
Seaside is the one example where we are using semantic versioning, precisely because we ran into the problems you described. We have #'release3', #'release3.0' #'release3.1' and will soon have #'release3.2'. #'release3' points to #'release3.1', so if you don't care about the api changes from 3.0 to 3.1 you'll just use the latest stable. Otherwise, use #'release3.1'. We'll do bug fixes on the numbered versions, and make sure that they work with the latest versions. Depending on a numbered version will force you to keep up with every change in Seaside, especially because a lot of new versions are due to changes in Pharo. So, if you depend on Seaside, Grease or Magritte: you probably don't want to depend on #stable (nor #bleedingEdge), but on a #'releaseX.X'.
that of course introduces other kind of problems, like: what happens if I want to install Project A who depends on Seaside/3.0 and Project B who depends on Seaside/3.0.2
Yep, both should depend on #'release3.0'. That way, your code might even run on Pharo 4, and profit from the bug fixes done between 3.0.2 and the current 3.0.16 Stephan
it was just an example of why using #stable in project dependences is a bad idea :) you made #releaseN.N to fix precisely my point. but since this is a convention of Seaside and not a regular practice⦠who knows it? (not saying that is wrong, is in fact very good, but there should exist something like I say â3.*â) btw⦠IMO other frequent misunderstanding is the use of metacello as description for nightly builds. metacello (and any dependency manager) should be use *just* for releases. think other dependecy managers around: maven, npm or whatever⦠they are used to describe and publish projects people actually can download and use. Any version: 3.0 3.0.1 3.1 ⦠etc. is a loadable and usable version. the concept of stable/release/etc. is just incorrect: all published versions should be stable and released. we need to separate the concept of âartifact releasedâ and âdevelopment branchâ, and we need to stop using versions as commits. In my opinion development cycle should be: we release version 1.0 then we develop in bleeding edge lets say for doing a version 1.1 we want a bug fix for 1.0 while developing 1.1? then we install 1.0, make a fix, and publish 1.0.1 we continue in #bleedingEdge until we are ready to: 1.1-alpha 1.1-beta 1.1-rc1 1.1 we repeat the cycle for next version etc. Iâm sorry for being obvious here, I know this is known⦠problem is that Iâve seen far too much the use of metacello not for doing releases but to handle commits. cheers, Esteban
On 12 Jun 2015, at 10:04, Stephan Eggermont <stephan@stack.nl> wrote:
On 12-06-15 09:34, Esteban Lorenzano wrote:
Project A uses for instance Seaside stable which is, when Project A starts Seaside 3.0 time after owner tries to load Project A⦠but since then stable from Seaside has move from Seaside 3.0, to 3.1.2
Seaside is the one example where we are using semantic versioning, precisely because we ran into the problems you described. We have #'release3', #'release3.0' #'release3.1' and will soon have #'release3.2'. #'release3' points to #'release3.1', so if you don't care about the api changes from 3.0 to 3.1 you'll just use the latest stable. Otherwise, use #'release3.1'.
We'll do bug fixes on the numbered versions, and make sure that they work with the latest versions. Depending on a numbered version will force you to keep up with every change in Seaside, especially because a lot of new versions are due to changes in Pharo.
So, if you depend on Seaside, Grease or Magritte: you probably don't want to depend on #stable (nor #bleedingEdge), but on a #'releaseX.X'.
that of course introduces other kind of problems, like: what happens if I want to install Project A who depends on Seaside/3.0 and Project B who depends on Seaside/3.0.2
Yep, both should depend on #'release3.0'. That way, your code might even run on Pharo 4, and profit from the bug fixes done between 3.0.2 and the current 3.0.16
Stephan
On 12-06-15 10:24, Esteban Lorenzano wrote:
it was just an example of why using #stable in project dependences is a bad idea :) you made #releaseN.N to fix precisely my point. there should exist something like I say â3.*â
#'release3' always refers to the latest stable 3.*.*.*
Iâm sorry for being obvious here, I know this is known⦠problem is that Iâve seen far too much the use of metacello not for doing releases but to handle commits.
I think it mostly has to do with the need to have exact reproducible builds (which is different from the need to have working software). That would be better handled with a (separate) SnapshotOf class i.m.o. Stephan
On 12 Jun 2015, at 10:40, Stephan Eggermont <stephan@stack.nl> wrote:
On 12-06-15 10:24, Esteban Lorenzano wrote:
it was just an example of why using #stable in project dependences is a bad idea :) you made #releaseN.N to fix precisely my point. there should exist something like I say â3.*â
#'release3' always refers to the latest stable 3.*.*.*
I know :) Iâm just saying that I would like to have that as a standard mechanism, not a convention. Esteban
Iâm sorry for being obvious here, I know this is known⦠problem is that Iâve seen far too much the use of metacello not for doing releases but to handle commits.
I think it mostly has to do with the need to have exact reproducible builds (which is different from the need to have working software). That would be better handled with a (separate) SnapshotOf class i.m.o.
Stephan
Just a quick side note: my initial email was kind of a troll. Because when you ask for something about roassal and 3D, you get a reply about Roassal-Woden i.e. Roassal3D is not supported anymore, you have to use Woden instead. Now when you have to load Woden, you canât so you have to use the uber-long script on the Woden project page instead of conf. Thatâs why Iâve joked about using scripts instead of Metacello. Uko
On 12 Jun 2015, at 12:25, Esteban Lorenzano <estebanlm@gmail.com> wrote:
On 12 Jun 2015, at 10:40, Stephan Eggermont <stephan@stack.nl> wrote:
On 12-06-15 10:24, Esteban Lorenzano wrote:
it was just an example of why using #stable in project dependences is a bad idea :) you made #releaseN.N to fix precisely my point. there should exist something like I say â3.*â
#'release3' always refers to the latest stable 3.*.*.*
I know :) Iâm just saying that I would like to have that as a standard mechanism, not a convention.
Esteban
Iâm sorry for being obvious here, I know this is known⦠problem is that Iâve seen far too much the use of metacello not for doing releases but to handle commits.
I think it mostly has to do with the need to have exact reproducible builds (which is different from the need to have working software). That would be better handled with a (separate) SnapshotOf class i.m.o.
Stephan
On Fri, Jun 12, 2015 at 1:48 PM, Yuriy Tymchuk <yuriy.tymchuk@me.com> wrote:
Just a quick side note:
my initial email was kind of a troll. Because when you ask for something about roassal and 3D, you get a reply about Roassal-Woden i.e. Roassal3D is not supported anymore, you have to use Woden instead. Now when you have to load Woden, you canât so you have to use the uber-long script on the Woden project page instead of conf. Thatâs why Iâve joked about using scripts instead of Metacello.
Uko
On 12 Jun 2015, at 12:25, Esteban Lorenzano <estebanlm@gmail.com> wrote:
On 12 Jun 2015, at 10:40, Stephan Eggermont <stephan@stack.nl> wrote:
On 12-06-15 10:24, Esteban Lorenzano wrote:
it was just an example of why using #stable in project dependences is a bad idea :) you made #releaseN.N to fix precisely my point. there should exist something like I say â3.*â
#'release3' always refers to the latest stable 3.*.*.*
I know :) Iâm just saying that I would like to have that as a standard mechanism, not a convention.
As a sidenote (and since Yuriy mentioned Roassal), we would like to address the versioning (and release management) of roassal at ESUG (Camp Roassal) since Roassal was being developed really fast and it was hard to keep up. Semver is good for not breaking things (if applied properly), but I feel it hides a little bit the extent of change... a project could go from version 1 to 10 with several very little bc-breaks and then from 10 to 11 there would be complete redesign... and you can't tell the difference just looking at the number, which is bad for updating ( As for #stable, etc., they are very useful for tools which I only use as a user... e.g. PharoLauncher or QualityAssistant my 2¢ Peter
+1
On Jun 12, 2015, at 9:36 AM, Peter Uhnák <i.uhnak@gmail.com> wrote:
As a sidenote (and since Yuriy mentioned Roassal), we would like to address the versioning (and release management) of roassal at ESUG (Camp Roassal) since Roassal was being developed really fast and it was hard to keep up.
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Yuriy can you check with JB because he told me that he wrote a configuration for Wooden. Stef Le 12/6/15 13:48, Yuriy Tymchuk a écrit :Yuri
Just a quick side note:
my initial email was kind of a troll. Because when you ask for something about roassal and 3D, you get a reply about Roassal-Woden i.e. Roassal3D is not supported anymore, you have to use Woden instead. Now when you have to load Woden, you canât so you have to use the uber-long script on the Woden project page instead of conf. Thatâs why Iâve joked about using scripts instead of Metacello.
Uko
On 12 Jun 2015, at 12:25, Esteban Lorenzano <estebanlm@gmail.com> wrote:
On 12 Jun 2015, at 10:40, Stephan Eggermont <stephan@stack.nl> wrote:
On 12-06-15 10:24, Esteban Lorenzano wrote:
it was just an example of why using #stable in project dependences is a bad idea :) you made #releaseN.N to fix precisely my point. there should exist something like I say â3.*â #'release3' always refers to the latest stable 3.*.*.* I know :) Iâm just saying that I would like to have that as a standard mechanism, not a convention.
Esteban
Iâm sorry for being obvious here, I know this is known⦠problem is that Iâve seen far too much the use of metacello not for doing releases but to handle commits. I think it mostly has to do with the need to have exact reproducible builds (which is different from the need to have working software). That would be better handled with a (separate) SnapshotOf class i.m.o.
Stephan
Hi Stef. Yes, there is âjenkinsâ baseline, but after some time it stopped working. The problem is that JB cannot really maintain configuration of the projects developed by other people, because he is not aware what has changed and needs significantly more time than the dev that work with it. Uko
On 25 Jun 2015, at 20:14, stepharo <stepharo@free.fr> wrote:
Yuriy
can you check with JB because he told me that he wrote a configuration for Wooden.
Stef
Le 12/6/15 13:48, Yuriy Tymchuk a écrit :Yuri
Just a quick side note:
my initial email was kind of a troll. Because when you ask for something about roassal and 3D, you get a reply about Roassal-Woden i.e. Roassal3D is not supported anymore, you have to use Woden instead. Now when you have to load Woden, you canât so you have to use the uber-long script on the Woden project page instead of conf. Thatâs why Iâve joked about using scripts instead of Metacello.
Uko
On 12 Jun 2015, at 12:25, Esteban Lorenzano <estebanlm@gmail.com> wrote:
On 12 Jun 2015, at 10:40, Stephan Eggermont <stephan@stack.nl> wrote:
On 12-06-15 10:24, Esteban Lorenzano wrote:
it was just an example of why using #stable in project dependences is a bad idea :) you made #releaseN.N to fix precisely my point. there should exist something like I say â3.*â #'release3' always refers to the latest stable 3.*.*.* I know :) Iâm just saying that I would like to have that as a standard mechanism, not a convention.
Esteban
Iâm sorry for being obvious here, I know this is known⦠problem is that Iâve seen far too much the use of metacello not for doing releases but to handle commits. I think it mostly has to do with the need to have exact reproducible builds (which is different from the need to have working software). That would be better handled with a (separate) SnapshotOf class i.m.o.
Stephan
But we need a working configuration for a Thales project so it has to work. Stef Le 25/6/15 20:59, Yuriy Tymchuk a écrit :
Hi Stef.
Yes, there is âjenkinsâ baseline, but after some time it stopped working. The problem is that JB cannot really maintain configuration of the projects developed by other people, because he is not aware what has changed and needs significantly more time than the dev that work with it.
Uko
On 25 Jun 2015, at 20:14, stepharo <stepharo@free.fr> wrote:
Yuriy
can you check with JB because he told me that he wrote a configuration for Wooden.
Stef
Le 12/6/15 13:48, Yuriy Tymchuk a écrit :Yuri
Just a quick side note:
my initial email was kind of a troll. Because when you ask for something about roassal and 3D, you get a reply about Roassal-Woden i.e. Roassal3D is not supported anymore, you have to use Woden instead. Now when you have to load Woden, you canât so you have to use the uber-long script on the Woden project page instead of conf. Thatâs why Iâve joked about using scripts instead of Metacello.
Uko
On 12 Jun 2015, at 12:25, Esteban Lorenzano <estebanlm@gmail.com> wrote:
On 12 Jun 2015, at 10:40, Stephan Eggermont <stephan@stack.nl> wrote:
On 12-06-15 10:24, Esteban Lorenzano wrote:
it was just an example of why using #stable in project dependences is a bad idea :) you made #releaseN.N to fix precisely my point. there should exist something like I say â3.*â #'release3' always refers to the latest stable 3.*.*.* I know :) Iâm just saying that I would like to have that as a standard mechanism, not a convention.
Esteban
Iâm sorry for being obvious here, I know this is known⦠problem is that Iâve seen far too much the use of metacello not for doing releases but to handle commits. I think it mostly has to do with the need to have exact reproducible builds (which is different from the need to have working software). That would be better handled with a (separate) SnapshotOf class i.m.o.
Stephan
Hi. I tried to load Woden into pharo 4 and 5 images using script: Gofer new smalltalkhubUser: 'ronsaldoâ project: 'Wodenâ; package: 'ConfigurationOfWodenâ; load. (#ConfigurationOfWoden asClass project version: #jenkins) load And in both cases I got the error: 'Name not found: WithOpenGLAndExamplesâ. It looks like version #jenkins, created by JB, doesnât work. Best regards, Natalia
On 25 Jun 2015, at 20:14, stepharo <stepharo@free.fr> wrote:
Yuriy
can you check with JB because he told me that he wrote a configuration for Wooden.
Stef
Le 12/6/15 13:48, Yuriy Tymchuk a écrit :Yuri
Just a quick side note:
my initial email was kind of a troll. Because when you ask for something about roassal and 3D, you get a reply about Roassal-Woden i.e. Roassal3D is not supported anymore, you have to use Woden instead. Now when you have to load Woden, you canât so you have to use the uber-long script on the Woden project page instead of conf. Thatâs why Iâve joked about using scripts instead of Metacello.
Uko
On 12 Jun 2015, at 12:25, Esteban Lorenzano <estebanlm@gmail.com> wrote:
On 12 Jun 2015, at 10:40, Stephan Eggermont <stephan@stack.nl> wrote:
On 12-06-15 10:24, Esteban Lorenzano wrote:
it was just an example of why using #stable in project dependences is a bad idea :) you made #releaseN.N to fix precisely my point. there should exist something like I say â3.*â #'release3' always refers to the latest stable 3.*.*.* I know :) Iâm just saying that I would like to have that as a standard mechanism, not a convention.
Esteban
Iâm sorry for being obvious here, I know this is known⦠problem is that Iâve seen far too much the use of metacello not for doing releases but to handle commits. I think it mostly has to do with the need to have exact reproducible builds (which is different from the need to have working software). That would be better handled with a (separate) SnapshotOf class i.m.o.
Stephan
Hi, As i said earlier in the conversation, you have to unload the oswindow configuration first... Just execute this before loading the package: MCPackageLoader unloadPackage: (MCPackage named: 'ConfigurationOfOSWindow') Merwan On mar., 2015-07-07 at 17:13 +0200, Natalia Tymchuk wrote:
Hi.
I tried to load Woden into pharo 4 and 5 images using script:
Gofer new smalltalkhubUser: 'ronsaldoâ project: 'Wodenâ; package: 'ConfigurationOfWodenâ; load. (#ConfigurationOfWoden asClass project version: #jenkins) load
And in both cases I got the error: 'Name not found: WithOpenGLAndExamplesâ. It looks like version #jenkins, created by JB, doesnât work.
Best regards, Natalia
On 25 Jun 2015, at 20:14, stepharo <stepharo@free.fr> wrote:
Yuriy
can you check with JB because he told me that he wrote a configuration for Wooden.
Stef
Le 12/6/15 13:48, Yuriy Tymchuk a écrit :Yuri
Just a quick side note:
my initial email was kind of a troll. Because when you ask for something about roassal and 3D, you get a reply about Roassal-Woden i.e. Roassal3D is not supported anymore, you have to use Woden instead. Now when you have to load Woden, you canât so you have to use the uber-long script on the Woden project page instead of conf. Thatâs why Iâve joked about using scripts instead of Metacello.
Uko
On 12 Jun 2015, at 12:25, Esteban Lorenzano <estebanlm@gmail.com> wrote:
On 12 Jun 2015, at 10:40, Stephan Eggermont <stephan@stack.nl> wrote:
On 12-06-15 10:24, Esteban Lorenzano wrote:
it was just an example of why using #stable in project dependences is a bad idea :) you made #releaseN.N to fix precisely my point. there should exist something like I say â3.*â #'release3' always refers to the latest stable 3.*.*.* I know :) Iâm just saying that I would like to have that as a standard mechanism, not a convention.
Esteban
Iâm sorry for being obvious here, I know this is known⦠problem is that Iâve seen far too much the use of metacello not for doing releases but to handle commits. I think it mostly has to do with the need to have exact reproducible builds (which is different from the need to have working software). That would be better handled with a (separate) SnapshotOf class i.m.o.
Stephan
On 06/12/2015 01:24 AM, Esteban Lorenzano wrote:
it was just an example of why using #stable in project dependences is a bad idea :) you made #releaseN.N to fix precisely my point. but since this is a convention of Seaside and not a regular practice⦠who knows it? (not saying that is wrong, is in fact very good, but there should exist something like I say â3.*â)
btw⦠IMO other frequent misunderstanding is the use of metacello as description for nightly builds. metacello (and any dependency manager) should be use *just* for releases. think other dependecy managers around: maven, npm or whatever⦠they are used to describe and publish projects people actually can download and use. Any version:
3.0 3.0.1 3.1 ⦠etc.
is a loadable and usable version. the concept of stable/release/etc. is just incorrect: all published versions should be stable and released.
we need to separate the concept of âartifact releasedâ and âdevelopment branchâ, and we need to stop using versions as commits. In my opinion development cycle should be:
we release version 1.0 then we develop in bleeding edge lets say for doing a version 1.1 we want a bug fix for 1.0 while developing 1.1? then we install 1.0, make a fix, and publish 1.0.1 we continue in #bleedingEdge until we are ready to: 1.1-alpha 1.1-beta 1.1-rc1 1.1 we repeat the cycle for next version etc.
Iâm sorry for being obvious here, I know this is known⦠problem is that Iâve seen far too much the use of metacello not for doing releases but to handle commits.
Esteban, this point is exactly the reason that I am a proponent of using git. Branches are first class objects in git and provide exactly the type of functionality that is needed for doing development where problems are being solved on multiple fronts. I've added features to the Metacello Scripting API over the last couple of years to make it possible to switch between github-based repos and local git clones which is critical for development and So I don't think that "Metacello shouldn't be used for nightly builds", but that "ConfigurationOf shouldn't be used for nightly builds":) I've recently posted an article on the Metacello news group[1] where I talk in more detail about using Metacello and git for development. Dale [1] http://forum.world.st/GitHub-Configs-tp4830432p4830673.html
⦠and of course I agree 100% with you :) the real problem is how do we get there, and Iâm thinking not just the tools, but the âcultural changeâ. Esteban
On 12 Jun 2015, at 19:41, Dale Henrichs <dale.henrichs@gemtalksystems.com> wrote:
On 06/12/2015 01:24 AM, Esteban Lorenzano wrote:
it was just an example of why using #stable in project dependences is a bad idea :) you made #releaseN.N to fix precisely my point. but since this is a convention of Seaside and not a regular practice⦠who knows it? (not saying that is wrong, is in fact very good, but there should exist something like I say â3.*â)
btw⦠IMO other frequent misunderstanding is the use of metacello as description for nightly builds. metacello (and any dependency manager) should be use *just* for releases. think other dependecy managers around: maven, npm or whatever⦠they are used to describe and publish projects people actually can download and use. Any version:
3.0 3.0.1 3.1 ⦠etc.
is a loadable and usable version. the concept of stable/release/etc. is just incorrect: all published versions should be stable and released.
we need to separate the concept of âartifact releasedâ and âdevelopment branchâ, and we need to stop using versions as commits. In my opinion development cycle should be:
we release version 1.0 then we develop in bleeding edge lets say for doing a version 1.1 we want a bug fix for 1.0 while developing 1.1? then we install 1.0, make a fix, and publish 1.0.1 we continue in #bleedingEdge until we are ready to: 1.1-alpha 1.1-beta 1.1-rc1 1.1 we repeat the cycle for next version etc.
Iâm sorry for being obvious here, I know this is known⦠problem is that Iâve seen far too much the use of metacello not for doing releases but to handle commits.
Esteban, this point is exactly the reason that I am a proponent of using git.
Branches are first class objects in git and provide exactly the type of functionality that is needed for doing development where problems are being solved on multiple fronts.
I've added features to the Metacello Scripting API over the last couple of years to make it possible to switch between github-based repos and local git clones which is critical for development and
So I don't think that "Metacello shouldn't be used for nightly builds", but that "ConfigurationOf shouldn't be used for nightly builds":)
I've recently posted an article on the Metacello news group[1] where I talk in more detail about using Metacello and git for development.
Dale
[1] http://forum.world.st/GitHub-Configs-tp4830432p4830673.html <http://forum.world.st/GitHub-Configs-tp4830432p4830673.html>
Esteban, Yeah, it can take time for the culture to change, but the tools do have to be in place and the early adopters have to beat those tools into shape ... we are in this phase at the moment I think... once the tools are in place, then the projects that are feeling the most pain will have the opportunity to make the transition with a minimum amount of fuss and if the pain is reduced (which I expect to happen) others will follow ... Dale On 06/13/2015 12:56 AM, Esteban Lorenzano wrote:
⦠and of course I agree 100% with you :) the real problem is how do we get there, and Iâm thinking not just the tools, but the âcultural changeâ.
Esteban
On 12 Jun 2015, at 19:41, Dale Henrichs <dale.henrichs@gemtalksystems.com <mailto:dale.henrichs@gemtalksystems.com>> wrote:
On 06/12/2015 01:24 AM, Esteban Lorenzano wrote:
it was just an example of why using #stable in project dependences is a bad idea :) you made #releaseN.N to fix precisely my point. but since this is a convention of Seaside and not a regular practice⦠who knows it? (not saying that is wrong, is in fact very good, but there should exist something like I say â3.*â)
btw⦠IMO other frequent misunderstanding is the use of metacello as description for nightly builds. metacello (and any dependency manager) should be use *just* for releases. think other dependecy managers around: maven, npm or whatever⦠they are used to describe and publish projects people actually can download and use. Any version:
3.0 3.0.1 3.1 ⦠etc.
is a loadable and usable version. the concept of stable/release/etc. is just incorrect: all published versions should be stable and released.
we need to separate the concept of âartifact releasedâ and âdevelopment branchâ, and we need to stop using versions as commits. In my opinion development cycle should be:
we release version 1.0 then we develop in bleeding edge lets say for doing a version 1.1 we want a bug fix for 1.0 while developing 1.1? then we install 1.0, make a fix, and publish 1.0.1 we continue in #bleedingEdge until we are ready to: 1.1-alpha 1.1-beta 1.1-rc1 1.1 we repeat the cycle for next version etc.
Iâm sorry for being obvious here, I know this is known⦠problem is that Iâve seen far too much the use of metacello not for doing releases but to handle commits.
Esteban, this point is exactly the reason that I am a proponent of using git.
Branches are first class objects in git and provide exactly the type of functionality that is needed for doing development where problems are being solved on multiple fronts.
I've added features to the Metacello Scripting API over the last couple of years to make it possible to switch between github-based repos and local git clones which is critical for development and
So I don't think that "Metacello shouldn't be used for nightly builds", but that "ConfigurationOf shouldn't be used for nightly builds":)
I've recently posted an article on the Metacello news group[1] where I talk in more detail about using Metacello and git for development.
Dale
[1]http://forum.world.st/GitHub-Configs-tp4830432p4830673.html
participants (11)
-
Alexandre Bergel -
Christophe Demarey -
Dale Henrichs -
Esteban Lorenzano -
Igor Stasenko -
Merwan Ouddane -
Natalia Tymchuk -
Peter Uhnák -
Stephan Eggermont -
stepharo -
Yuriy Tymchuk