[Pharo-project] How to define a ConfigurationOf with a #development version that depends on a baseline?
http://stackoverflow.com/questions/15762706/how-to-define-a-configurationof-... -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill
Am 02.04.2013 um 13:15 schrieb Damien Cassou <damien.cassou@gmail.com>:
http://stackoverflow.com/questions/15762706/how-to-define-a-configurationof-...
Just a question: Is there any plan for a Metacello 2? We have learnt a lot and we have a clear idea on a number of versioning scenarios. What do we want the future of packaging in Pharo to look like? Alexandre On Apr 2, 2013, at 7:15 AM, Damien Cassou <damien.cassou@gmail.com> wrote:
http://stackoverflow.com/questions/15762706/how-to-define-a-configurationof-...
-- Damien Cassou http://damiencassou.seasidehosting.st
"Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On Apr 5, 2013, at 11:28 PM, Alexandre Bergel <alexandre.bergel@me.com> wrote:
Just a question: Is there any plan for a Metacello 2? We have learnt a lot and we have a clear idea on a number of versioning scenarios. What do we want the future of packaging in Pharo to look like?
can you describe your scenario because we want versionner++ to support some keys scenarios and not all of them. Christophe is working on TravisCI so that dale can work with Pharo2.0 Stef
Alexandre
On Apr 2, 2013, at 7:15 AM, Damien Cassou <damien.cassou@gmail.com> wrote:
http://stackoverflow.com/questions/15762706/how-to-define-a-configurationof-...
-- Damien Cassou http://damiencassou.seasidehosting.st
"Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
In all the discussions about how to manage/organize Smalltalk code - I would like to add, that ENVY (though it's so old) with its config maps, applications, prerequisites is a pretty good example how it works. Take a look at the only available ENVY implementation today (VAST) and think about the way they did it in the eighties ... The ENVY-(concept - not the implementation) is still a master peace in this area - even when compared with VS or Eclipse - and it supports the power of Smalltalk very much. There are questionable parts of ENVY and I do not use these parts of it very often. But even these questionable parts of ENVY have not been better solved by other Smalltalk source code management systems. I've repositories, which are around 10 years old - and ALL code is still there, all versions for all different platforms - down to methods differences within a mouse click and the speed within a LAN is so good. Marten
On Apr 5, 2013, at 11:28 PM, Alexandre Bergel<alexandre.bergel@me.com> wrote:
Just a question: Is there any plan for a Metacello 2?
martin we worked with envy during 8 years for the moose dev on VW and I have the book of joseph. Now what is the process? during dev everybody load bleeding edge of the current maps? when frozen exact ersion are loaded? Stef
In all the discussions about how to manage/organize Smalltalk code - I would like to add, that ENVY (though it's so old) with its config maps, applications, prerequisites is a pretty good example how it works.
Take a look at the only available ENVY implementation today (VAST) and think about the way they did it in the eighties ...
The ENVY-(concept - not the implementation) is still a master peace in this area - even when compared with VS or Eclipse - and it supports the power of Smalltalk very much.
There are questionable parts of ENVY and I do not use these parts of it very often. But even these questionable parts of ENVY have not been better solved by other Smalltalk source code management systems.
I've repositories, which are around 10 years old - and ALL code is still there, all versions for all different platforms - down to methods differences within a mouse click and the speed within a LAN is so good.
Marten
On Apr 5, 2013, at 11:28 PM, Alexandre Bergel<alexandre.bergel@me.com> wrote:
Just a question: Is there any plan for a Metacello 2?
<marten.vcf>
Hi Marten, Frankly speaking, I find Envy way too complicated. I am using it these days and I am really not happy with. If I have to read a book to understand how it works, than there is no way I can teach students on how to use it in a reasonable amount of time. Configuration Map, Application, edition, scratch version and many more are way too many concepts, in my opinion. Alexandre On Apr 6, 2013, at 5:03 AM, Marten Feldtmann <marten@schrievkrom.de> wrote:
In all the discussions about how to manage/organize Smalltalk code - I would like to add, that ENVY (though it's so old) with its config maps, applications, prerequisites is a pretty good example how it works.
Take a look at the only available ENVY implementation today (VAST) and think about the way they did it in the eighties ...
The ENVY-(concept - not the implementation) is still a master peace in this area - even when compared with VS or Eclipse - and it supports the power of Smalltalk very much.
There are questionable parts of ENVY and I do not use these parts of it very often. But even these questionable parts of ENVY have not been better solved by other Smalltalk source code management systems.
I've repositories, which are around 10 years old - and ALL code is still there, all versions for all different platforms - down to methods differences within a mouse click and the speed within a LAN is so good.
Marten
On Apr 5, 2013, at 11:28 PM, Alexandre Bergel<alexandre.bergel@me.com> wrote:
Just a question: Is there any plan for a Metacello 2?
<marten.vcf>
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Alexandre, I had the same feeling, when I had to use it starting around 1997 in our company :-) We are now C#'pers, but it is interesting to see, that one item is remembered by all persons in our team from the Smalltalk-epoche in our company in a friendly way: ENVY. This was the item, which seem to impressed most of the people - especially *after* switching to VS. Marten On 07.04.2013 04:48, Alexandre Bergel wrote:
Hi Marten,
Frankly speaking, I find Envy way too complicated. I am using it these days and I am really not happy with. If I have to read a book to understand how it works, than there is no way I can teach students on how to use it in a reasonable amount of time. Configuration Map, Application, edition, scratch version and many more are way too many concepts, in my opinion.
I also worked with Envy for more than 10 years and after getting used to it (which took a certain time), it was the stable base for my daily work. Now I am learning to work with metacello/monticello. I find myself regularly thinking "hm, in Envy it was ...". I think that taking some of the principles of Envy would make sense. Sabine Von meinem iPad gesendet Am 07.04.2013 um 10:12 schrieb Marten Feldtmann <marten@schrievkrom.de>:
Alexandre,
I had the same feeling, when I had to use it starting around 1997 in our company :-)
We are now C#'pers, but it is interesting to see, that one item is remembered by all persons in our team from the Smalltalk-epoche in our company in a friendly way: ENVY.
This was the item, which seem to impressed most of the people - especially *after* switching to VS.
Marten
On 07.04.2013 04:48, Alexandre Bergel wrote:
Hi Marten,
Frankly speaking, I find Envy way too complicated. I am using it these days and I am really not happy with. If I have to read a book to understand how it works, than there is no way I can teach students on how to use it in a reasonable amount of time. Configuration Map, Application, edition, scratch version and many more are way too many concepts, in my opinion. <marten.vcf>
Just a question: Is there any plan for a Metacello 2? We have learnt a lot and we have a clear idea on a number of versioning scenarios. What do we want the future of packaging in Pharo to look like?
can you describe your scenario because we want versionner++ to support some keys scenarios and not all of them. Christophe is working on TravisCI so that dale can work with Pharo2.0
The minimum I need to live is creating a new version by saving all the Monticello packages. It should be easy to add new dependencies. This is what I somehow have with Versionner (except for the dependencies). I know this will probably not be enough to manage Pharo or Moose, but this will be more than enough for many of us I guess. A nice feature would be to have not-predefined tags on a version (e.g., #myStableVersion #deployedVersion). Things like groups, common platform, dependencies between baselines... I am not really convinced they help me. Maybe this is too complex for me to really understand them. I know there are some documentation. But I cannot afford to read a .pdf each time I need to define a new baseline or add a dependency. I just want to press a "commit" button, as it is done in most versioning systems. The versioning model should also be simple in such a way I can run some analyzes on it (e.g., did I forget to specify a dependency? Do I have cycles in my dependencies?). Alexandre
On Apr 2, 2013, at 7:15 AM, Damien Cassou <damien.cassou@gmail.com> wrote:
http://stackoverflow.com/questions/15762706/how-to-define-a-configurationof-...
-- Damien Cassou http://damiencassou.seasidehosting.st
"Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Hi. And what you think about OOSCM which was presented at last ESUG<https://www.google.com/calendar/render?eid=bmI4dDNuYnVoM3BrYXUwMTJ2Nzl2a2VwdHMgdG85cmJ2cTRpNzFtZ2d1bWdicHUyM2I5dGtAZw&ctz=Europe/Paris&pli=1&sf=true&output=xml>(and maybe at 2010 too)? Does Pharo wants such kind of technology? 2013/4/6 Alexandre Bergel <alexandre.bergel@me.com>
Just a question: Is there any plan for a Metacello 2? We have learnt a lot and we have a clear idea on a number of versioning scenarios. What do we want the future of packaging in Pharo to look like?
Alexandre
On Apr 2, 2013, at 7:15 AM, Damien Cassou <damien.cassou@gmail.com> wrote:
http://stackoverflow.com/questions/15762706/how-to-define-a-configurationof-...
-- Damien Cassou http://damiencassou.seasidehosting.st
"Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
This is not a question of wanting or not. The key question is - does it scale - do we have the manpower to maintain it - is it key for the future Stef
Hi.
And what you think about OOSCM which was presented at last ESUG (and maybe at 2010 too)?
Does Pharo wants such kind of technology?
2013/4/6 Alexandre Bergel <alexandre.bergel@me.com> Just a question: Is there any plan for a Metacello 2? We have learnt a lot and we have a clear idea on a number of versioning scenarios. What do we want the future of packaging in Pharo to look like?
Alexandre
On Apr 2, 2013, at 7:15 AM, Damien Cassou <damien.cassou@gmail.com> wrote:
http://stackoverflow.com/questions/15762706/how-to-define-a-configurationof-...
-- Damien Cassou http://damiencassou.seasidehosting.st
"Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
participants (7)
-
Alexandre Bergel -
Damien Cassou -
Denis Kudriashov -
Marten Feldtmann -
Sabine Knöfel -
stephane ducasse -
Tobias Pape