Re: [Pharo-dev] Roassal Camp Smalltalk

[stepharo]

Alex

what are your criteria for knowing if this is stable?

Because Roassal 2 got completely different from roassal 1.
So people used mondrian, then roassal (the changes was important and 
good there).

then we got roassal 2 which did not follow the same API
and worse is changing. So from a user perspective rewriting is boring.

So how do you assess that doing x that way is better expressed?
How can we help stabilizing the API?

Do not get me wrong I really want Roassal getting massively successful 
but it will not without:

- data importers
- stable API
- a slice of statistics

Stef

Le 16/6/15 23:53, Alexandre Bergel a écrit :

Yes, but the problem is that stabilizing an API that does not work is not 
productive.
In any case, July will be decisive for Roassal as I intent to push the book.

Alexandre



On Jun 15, 2015, at 4:00 AM, stepharo  wrote:

Hi Peter

Definitively. Having stable API is key for us and for everybody.
For us (synectique), we stop to change versions around 6 months ago.
This is sad that we have to shield us from Roassal but this is what we are 
doing.
We cannot fight to get clients and change all the time our code.
As you see, I'm the only one to say it because usman already reported this 
problem one year
ago and we discussed with alex but we faced the same problem and now he stopped 
even to report
problems.
So we will rediscuss in july when alex is visiting us and else we will stay 
with an old version.
The problem is that the community around roassal will not benefit from this but
we cannot do much.

Stef


Since I've already run into second thing in agile visualization book that is 
outdated (RTArrow, which was some time ago renamed to RTArrowedLine 
(https://dl.dropboxusercontent.com/u/31543901/AgileVisualization/Roassal/0104-Roassal.html
 section 2.2) it made me wonder how many things like these are there 
(considering in neither case I was looking for errors).

So, maybe this could be also addressed at the camp if there will be time?

Writing is hard and reviewing own work is exercise in futility (I see things 
that I want to see, not what is there). Some of it (like the examples) could be 
even executed to verify their validity.

And lastly what I saw in another thread (by stef) - graceful deprecation, and 
stabilization of API.

Peter

On Tue, Jun 9, 2015 at 9:57 PM, Yuriy Tymchuk  wrote:


On 08 Jun 2015, at 18:22, Alexandre Bergel  wrote:


Well at least for me it is certainly not clear what release policy is Roassal 
following; i.e. if I see a minor version change what to expect, if any BC 
breaks were introduced, etc. Of course this is extra effort for the person 
doing it, so it should be taken with care. But there are certainly things to be 
discussed about this.

Hi Peter,

Indeed, we have not been good at producing a descent version numbering schema.
My position was always this one: the last version should always fit your need. 
However, some product favored stability when Roassal is used in a commercial 
setting.
We will be more careful when updating the configuration with a proper version 
number.

Versioning is in fact a complex thing. That’s why I suggest to have a 
brainstorming session during the camp.

Uko


Cheers,
Alexandre



On Fri, Jun 5, 2015 at 7:31 PM, Yuriy Tymchuk  wrote:
Oh, then it’s my bad. Last time I’ve checked it seemed that it wasn’t updated 
for a long time. Maybe I was wrong.

Uko




On 05 Jun 2015, at 18:08, Peter Uhnák  wrote:

There sure are, look at ConfigurationOfRoassal2>>version*:

and in my baseline I have something like

~~~
spec
 project: 'Roassal2' with: [
 spec
 className: #ConfigurationOfRoassal2;
 versionString: '1.52';
 repository: 
'http://smalltalkhub.com/mc/ObjectProfile/Roassal2/main/' ];
~~~

Peter

On Fri, Jun 5, 2015 at 4:37 PM, Yuriy Tymchuk  wrote:
But are there numbered version to refer to?

Uko


On 05 Jun 2015, at 16:34, Peter Uhnák  wrote:



On Fri, Jun 5, 2015 at 3:29 PM, Yuriy Tymchuk  wrote:
I’m interested in participating. Personally I’d like to talk more about design 
decisions behind roassal ecosystem, release strategy and so on. Usually when I 
work with Roassal I have this issue that things are breaking because of rapid 
changes, or because of the differences between different parts of roassal. 
Maybe someone is also concerned about this, so we can discuss and maybe improve 
something…

Yes I am also interested in this, right now I am actually using quite old 
version (month+) because I didn't have time to keep up. :) (Arguably 90% of my 
problems were from infamous composite shapes. :))

Peter

Uko


On 04 Jun 2015, at 19:55, Alexandre Bergel  wrote:

Dear Colleagues and Friends,

We are happy to announce we will organize a CampSmalltalk about the Roassal 
visualization engine, on _Sunday 12 July_.

As far as we 

Re: [Pharo-dev] Roassal Camp Smalltalk

[Alexandre Bergel]

Yes, but the problem is that stabilizing an API that does not work is not 
productive. 
In any case, July will be decisive for Roassal as I intent to push the book.

Alexandre


> On Jun 15, 2015, at 4:00 AM, stepharo  wrote:
> 
> Hi Peter
> 
> Definitively. Having stable API is key for us and for everybody. 
> For us (synectique), we stop to change versions around 6 months ago. 
> This is sad that we have to shield us from Roassal but this is what we are 
> doing. 
> We cannot fight to get clients and change all the time our code.
> As you see, I'm the only one to say it because usman already reported this 
> problem one year
> ago and we discussed with alex but we faced the same problem and now he 
> stopped even to report
> problems.
> So we will rediscuss in july when alex is visiting us and else we will stay 
> with an old version. 
> The problem is that the community around roassal will not benefit from this 
> but 
> we cannot do much. 
> 
> Stef
> 
>> Since I've already run into second thing in agile visualization book that is 
>> outdated (RTArrow, which was some time ago renamed to RTArrowedLine 
>> (https://dl.dropboxusercontent.com/u/31543901/AgileVisualization/Roassal/0104-Roassal.html
>>  section 2.2) it made me wonder how many things like these are there 
>> (considering in neither case I was looking for errors).
>> 
>> So, maybe this could be also addressed at the camp if there will be time?
>> 
>> Writing is hard and reviewing own work is exercise in futility (I see things 
>> that I want to see, not what is there). Some of it (like the examples) could 
>> be even executed to verify their validity.
>> 
>> And lastly what I saw in another thread (by stef) - graceful deprecation, 
>> and stabilization of API.
>> 
>> Peter
>> 
>> On Tue, Jun 9, 2015 at 9:57 PM, Yuriy Tymchuk  wrote:
>> 
>> > On 08 Jun 2015, at 18:22, Alexandre Bergel  wrote:
>> >
>> >> Well at least for me it is certainly not clear what release policy is 
>> >> Roassal following; i.e. if I see a minor version change what to expect, 
>> >> if any BC breaks were introduced, etc. Of course this is extra effort for 
>> >> the person doing it, so it should be taken with care. But there are 
>> >> certainly things to be discussed about this.
>> >
>> > Hi Peter,
>> >
>> > Indeed, we have not been good at producing a descent version numbering 
>> > schema.
>> > My position was always this one: the last version should always fit your 
>> > need. However, some product favored stability when Roassal is used in a 
>> > commercial setting.
>> > We will be more careful when updating the configuration with a proper 
>> > version number.
>> 
>> Versioning is in fact a complex thing. That’s why I suggest to have a 
>> brainstorming session during the camp.
>> 
>> Uko
>> 
>> >
>> > Cheers,
>> > Alexandre
>> >
>> >
>> >>
>> >> On Fri, Jun 5, 2015 at 7:31 PM, Yuriy Tymchuk  
>> >> wrote:
>> >> Oh, then it’s my bad. Last time I’ve checked it seemed that it wasn’t 
>> >> updated for a long time. Maybe I was wrong.
>> >>
>> >> Uko
>> >>
>> >>
>> >>
>> >>> On 05 Jun 2015, at 18:08, Peter Uhnák  wrote:
>> >>>
>> >>> There sure are, look at ConfigurationOfRoassal2>>version*:
>> >>>
>> >>> and in my baseline I have something like
>> >>>
>> >>> ~~~
>> >>> spec
>> >>> project: 'Roassal2' with: [
>> >>> spec
>> >>> className: #ConfigurationOfRoassal2;
>> >>> versionString: '1.52';
>> >>> repository: 
>> >>> 'http://smalltalkhub.com/mc/ObjectProfile/Roassal2/main/' ];
>> >>> ~~~
>> >>>
>> >>> Peter
>> >>>
>> >>> On Fri, Jun 5, 2015 at 4:37 PM, Yuriy Tymchuk  
>> >>> wrote:
>> >>> But are there numbered version to refer to?
>> >>>
>> >>> Uko
>> >>>
>>  On 05 Jun 2015, at 16:34, Peter Uhnák  wrote:
>> 
>> 
>> 
>>  On Fri, Jun 5, 2015 at 3:29 PM, Yuriy Tymchuk  
>>  wrote:
>>  I’m interested in participating. Personally I’d like to talk more about 
>>  design decisions behind roassal ecosystem, release strategy and so on. 
>>  Usually when I work with Roassal I have this issue that things are 
>>  breaking because of rapid changes, or because of the differences 
>>  between different parts of roassal. Maybe someone is also concerned 
>>  about this, so we can discuss and maybe improve something…
>> 
>>  Yes I am also interested in this, right now I am actually using quite 
>>  old version (month+) because I didn't have time to keep up. :) 
>>  (Arguably 90% of my problems were from infamous composite shapes. :))
>> 
>>  Peter
>> 
>>  Uko
>> 
>> > On 04 Jun 2015, at 19:55, Alexandre Bergel  
>> > wrote:
>> >
>> > Dear Colleagues and Friends,
>> >
>> > We are happy to announce we will organize a CampSmalltalk about the 
>> > Roassal visualization engine, on _Sunday 12 July_.

Re: [Pharo-dev] Roassal Camp Smalltalk

[Alexandre Bergel]

Hi Peter,

I am really sorry about the instability. 
The book chapter has been updated.

Cheers,
Alexandre


> On Jun 14, 2015, at 7:10 PM, Peter Uhnák  wrote:
> 
> Since I've already run into second thing in agile visualization book that is 
> outdated (RTArrow, which was some time ago renamed to RTArrowedLine 
> (https://dl.dropboxusercontent.com/u/31543901/AgileVisualization/Roassal/0104-Roassal.html
>  section 2.2) it made me wonder how many things like these are there 
> (considering in neither case I was looking for errors).
> 
> So, maybe this could be also addressed at the camp if there will be time?
> 
> Writing is hard and reviewing own work is exercise in futility (I see things 
> that I want to see, not what is there). Some of it (like the examples) could 
> be even executed to verify their validity.
> 
> And lastly what I saw in another thread (by stef) - graceful deprecation, and 
> stabilization of API.
> 
> Peter
> 
> On Tue, Jun 9, 2015 at 9:57 PM, Yuriy Tymchuk  wrote:
> 
> > On 08 Jun 2015, at 18:22, Alexandre Bergel  wrote:
> >
> >> Well at least for me it is certainly not clear what release policy is 
> >> Roassal following; i.e. if I see a minor version change what to expect, if 
> >> any BC breaks were introduced, etc. Of course this is extra effort for the 
> >> person doing it, so it should be taken with care. But there are certainly 
> >> things to be discussed about this.
> >
> > Hi Peter,
> >
> > Indeed, we have not been good at producing a descent version numbering 
> > schema.
> > My position was always this one: the last version should always fit your 
> > need. However, some product favored stability when Roassal is used in a 
> > commercial setting.
> > We will be more careful when updating the configuration with a proper 
> > version number.
> 
> Versioning is in fact a complex thing. That’s why I suggest to have a 
> brainstorming session during the camp.
> 
> Uko
> 
> >
> > Cheers,
> > Alexandre
> >
> >
> >>
> >> On Fri, Jun 5, 2015 at 7:31 PM, Yuriy Tymchuk  wrote:
> >> Oh, then it’s my bad. Last time I’ve checked it seemed that it wasn’t 
> >> updated for a long time. Maybe I was wrong.
> >>
> >> Uko
> >>
> >>
> >>
> >>> On 05 Jun 2015, at 18:08, Peter Uhnák  wrote:
> >>>
> >>> There sure are, look at ConfigurationOfRoassal2>>version*:
> >>>
> >>> and in my baseline I have something like
> >>>
> >>> ~~~
> >>> spec
> >>> project: 'Roassal2' with: [
> >>> spec
> >>> className: #ConfigurationOfRoassal2;
> >>> versionString: '1.52';
> >>> repository: 
> >>> 'http://smalltalkhub.com/mc/ObjectProfile/Roassal2/main/' ];
> >>> ~~~
> >>>
> >>> Peter
> >>>
> >>> On Fri, Jun 5, 2015 at 4:37 PM, Yuriy Tymchuk  
> >>> wrote:
> >>> But are there numbered version to refer to?
> >>>
> >>> Uko
> >>>
>  On 05 Jun 2015, at 16:34, Peter Uhnák  wrote:
> 
> 
> 
>  On Fri, Jun 5, 2015 at 3:29 PM, Yuriy Tymchuk  
>  wrote:
>  I’m interested in participating. Personally I’d like to talk more about 
>  design decisions behind roassal ecosystem, release strategy and so on. 
>  Usually when I work with Roassal I have this issue that things are 
>  breaking because of rapid changes, or because of the differences between 
>  different parts of roassal. Maybe someone is also concerned about this, 
>  so we can discuss and maybe improve something…
> 
>  Yes I am also interested in this, right now I am actually using quite 
>  old version (month+) because I didn't have time to keep up. :) (Arguably 
>  90% of my problems were from infamous composite shapes. :))
> 
>  Peter
> 
>  Uko
> 
> > On 04 Jun 2015, at 19:55, Alexandre Bergel  
> > wrote:
> >
> > Dear Colleagues and Friends,
> >
> > We are happy to announce we will organize a CampSmalltalk about the 
> > Roassal visualization engine, on _Sunday 12 July_.
> >
> > As far as we have seen, the interests are multiple. Here is a list of 
> > topics we will happy to work on:
> >  - Port of Roassal on VisualWorks
> >  - Using Roassal on Gemstone
> >  - HTML/JavaScript export
> >  - Improving Grapher, our charting library
> >
> > If you wish to participate, get in touch with us. Since we will 
> > probably have a sponsoring of the event, it would be nice to know how 
> > many will attend to ease the logistic and the pizza ordering :-)
> >
> > Cheers,
> > Alexandre
> > --
> > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> > Alexandre Bergel  http://www.bergel.eu
> > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
> >
> >
> >
> >
> 
> 
> 
> >>>
> >>>
> >>
> >>
> >
> > --
> > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> > Alexandre Bergel  http://www.

Re: [Pharo-dev] Roassal Camp Smalltalk

[stepharo]

Hi Peter

Definitively. Having stable API is key for us and for everybody.
For us (synectique), we stop to change versions around 6 months ago.
This is sad that we have to shield us from Roassal but this is what we 
are doing.

We cannot fight to get clients and change all the time our code.
As you see, I'm the only one to say it because usman already reported 
this problem one year
ago and we discussed with alex but we faced the same problem and now he 
stopped even to report

problems.
So we will rediscuss in july when alex is visiting us and else we will 
stay with an old version.
The problem is that the community around roassal will not benefit from 
this but

we cannot do much.

Stef

Since I've already run into second thing in agile visualization book 
that is outdated (RTArrow, which was some time ago renamed to 
RTArrowedLine 
(https://dl.dropboxusercontent.com/u/31543901/AgileVisualization/Roassal/0104-Roassal.html 
section 2.2) it made me wonder how many things like these are there 
(considering in neither case I was looking for errors).


So, maybe this could be also addressed at the camp if there will be time?

Writing is hard and reviewing own work is exercise in futility (I see 
things that I want to see, not what is there). Some of it (like the 
examples) could be even executed to verify their validity.


And lastly what I saw in another thread (by stef) - graceful 
deprecation, and stabilization of API.


Peter

On Tue, Jun 9, 2015 at 9:57 PM, Yuriy Tymchuk > wrote:



> On 08 Jun 2015, at 18:22, Alexandre Bergel
mailto:alexandre.ber...@me.com>> wrote:
>
>> Well at least for me it is certainly not clear what release
policy is Roassal following; i.e. if I see a minor version change
what to expect, if any BC breaks were introduced, etc. Of course
this is extra effort for the person doing it, so it should be
taken with care. But there are certainly things to be discussed
about this.
>
> Hi Peter,
>
> Indeed, we have not been good at producing a descent version
numbering schema.
> My position was always this one: the last version should always
fit your need. However, some product favored stability when
Roassal is used in a commercial setting.
> We will be more careful when updating the configuration with a
proper version number.

Versioning is in fact a complex thing. That’s why I suggest to
have a brainstorming session during the camp.

Uko

>
> Cheers,
> Alexandre
>
>
>>
>> On Fri, Jun 5, 2015 at 7:31 PM, Yuriy Tymchuk
mailto:yuriy.tymc...@me.com>> wrote:
>> Oh, then it’s my bad. Last time I’ve checked it seemed that it
wasn’t updated for a long time. Maybe I was wrong.
>>
>> Uko
>>
>>
>>
>>> On 05 Jun 2015, at 18:08, Peter Uhnák mailto:i.uh...@gmail.com>> wrote:
>>>
>>> There sure are, look at ConfigurationOfRoassal2>>version*:
>>>
>>> and in my baseline I have something like
>>>
>>> ~~~
>>> spec
>>> project: 'Roassal2' with: [
>>> spec
>>>  className: #ConfigurationOfRoassal2;
>>>  versionString: '1.52';
>>>  repository:
'http://smalltalkhub.com/mc/ObjectProfile/Roassal2/main/' ];
>>> ~~~
>>>
>>> Peter
>>>
>>> On Fri, Jun 5, 2015 at 4:37 PM, Yuriy Tymchuk
mailto:yuriy.tymc...@me.com>> wrote:
>>> But are there numbered version to refer to?
>>>
>>> Uko
>>>
 On 05 Jun 2015, at 16:34, Peter Uhnák mailto:i.uh...@gmail.com>> wrote:



 On Fri, Jun 5, 2015 at 3:29 PM, Yuriy Tymchuk
mailto:yuriy.tymc...@me.com>> wrote:
 I’m interested in participating. Personally I’d like to talk
more about design decisions behind roassal ecosystem, release
strategy and so on. Usually when I work with Roassal I have this
issue that things are breaking because of rapid changes, or
because of the differences between different parts of roassal.
Maybe someone is also concerned about this, so we can discuss and
maybe improve something…

 Yes I am also interested in this, right now I am actually
using quite old version (month+) because I didn't have time to
keep up. :) (Arguably 90% of my problems were from infamous
composite shapes. :))

 Peter

 Uko

> On 04 Jun 2015, at 19:55, Alexandre Bergel
mailto:alexandre.ber...@me.com>> wrote:
>
> Dear Colleagues and Friends,
>
> We are happy to announce we will organize a CampSmalltalk
about the Roassal visualization engine, on _Sunday 12 July_.
>
> As far as we have seen, the interests are multiple. Here is
a list of topics we will happy to work on:
>  - Port of Roassal on VisualWorks
>  - Using Roassal on Gemston

Re: [Pharo-dev] Roassal Camp Smalltalk

[Peter Uhnák]

Since I've already run into second thing in agile visualization book that
is outdated (RTArrow, which was some time ago renamed to RTArrowedLine (
https://dl.dropboxusercontent.com/u/31543901/AgileVisualization/Roassal/0104-Roassal.html
section 2.2) it made me wonder how many things like these are there
(considering in neither case I was looking for errors).

So, maybe this could be also addressed at the camp if there will be time?

Writing is hard and reviewing own work is exercise in futility (I see
things that I want to see, not what is there). Some of it (like the
examples) could be even executed to verify their validity.

And lastly what I saw in another thread (by stef) - graceful deprecation,
and stabilization of API.

Peter

On Tue, Jun 9, 2015 at 9:57 PM, Yuriy Tymchuk  wrote:

>
> > On 08 Jun 2015, at 18:22, Alexandre Bergel 
> wrote:
> >
> >> Well at least for me it is certainly not clear what release policy is
> Roassal following; i.e. if I see a minor version change what to expect, if
> any BC breaks were introduced, etc. Of course this is extra effort for the
> person doing it, so it should be taken with care. But there are certainly
> things to be discussed about this.
> >
> > Hi Peter,
> >
> > Indeed, we have not been good at producing a descent version numbering
> schema.
> > My position was always this one: the last version should always fit your
> need. However, some product favored stability when Roassal is used in a
> commercial setting.
> > We will be more careful when updating the configuration with a proper
> version number.
>
> Versioning is in fact a complex thing. That’s why I suggest to have a
> brainstorming session during the camp.
>
> Uko
>
> >
> > Cheers,
> > Alexandre
> >
> >
> >>
> >> On Fri, Jun 5, 2015 at 7:31 PM, Yuriy Tymchuk 
> wrote:
> >> Oh, then it’s my bad. Last time I’ve checked it seemed that it wasn’t
> updated for a long time. Maybe I was wrong.
> >>
> >> Uko
> >>
> >>
> >>
> >>> On 05 Jun 2015, at 18:08, Peter Uhnák  wrote:
> >>>
> >>> There sure are, look at ConfigurationOfRoassal2>>version*:
> >>>
> >>> and in my baseline I have something like
> >>>
> >>> ~~~
> >>> spec
> >>> project: 'Roassal2' with: [
> >>> spec
> >>> className:
> #ConfigurationOfRoassal2;
> >>> versionString: '1.52';
> >>> repository: '
> http://smalltalkhub.com/mc/ObjectProfile/Roassal2/main/' ];
> >>> ~~~
> >>>
> >>> Peter
> >>>
> >>> On Fri, Jun 5, 2015 at 4:37 PM, Yuriy Tymchuk 
> wrote:
> >>> But are there numbered version to refer to?
> >>>
> >>> Uko
> >>>
>  On 05 Jun 2015, at 16:34, Peter Uhnák  wrote:
> 
> 
> 
>  On Fri, Jun 5, 2015 at 3:29 PM, Yuriy Tymchuk 
> wrote:
>  I’m interested in participating. Personally I’d like to talk more
> about design decisions behind roassal ecosystem, release strategy and so
> on. Usually when I work with Roassal I have this issue that things are
> breaking because of rapid changes, or because of the differences between
> different parts of roassal. Maybe someone is also concerned about this, so
> we can discuss and maybe improve something…
> 
>  Yes I am also interested in this, right now I am actually using quite
> old version (month+) because I didn't have time to keep up. :) (Arguably
> 90% of my problems were from infamous composite shapes. :))
> 
>  Peter
> 
>  Uko
> 
> > On 04 Jun 2015, at 19:55, Alexandre Bergel 
> wrote:
> >
> > Dear Colleagues and Friends,
> >
> > We are happy to announce we will organize a CampSmalltalk about the
> Roassal visualization engine, on _Sunday 12 July_.
> >
> > As far as we have seen, the interests are multiple. Here is a list
> of topics we will happy to work on:
> >  - Port of Roassal on VisualWorks
> >  - Using Roassal on Gemstone
> >  - HTML/JavaScript export
> >  - Improving Grapher, our charting library
> >
> > If you wish to participate, get in touch with us. Since we will
> probably have a sponsoring of the event, it would be nice to know how many
> will attend to ease the logistic and the pizza ordering :-)
> >
> > Cheers,
> > Alexandre
> > --
> > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> > Alexandre Bergel  http://www.bergel.eu
> > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
> >
> >
> >
> >
> 
> 
> 
> >>>
> >>>
> >>
> >>
> >
> > --
> > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> > Alexandre Bergel  http://www.bergel.eu
> > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
> >
> >
> >
> >
>
>
>

Re: [Pharo-dev] Roassal Camp Smalltalk

[Yuriy Tymchuk]

> On 08 Jun 2015, at 18:22, Alexandre Bergel  wrote:
> 
>> Well at least for me it is certainly not clear what release policy is 
>> Roassal following; i.e. if I see a minor version change what to expect, if 
>> any BC breaks were introduced, etc. Of course this is extra effort for the 
>> person doing it, so it should be taken with care. But there are certainly 
>> things to be discussed about this.
> 
> Hi Peter,
> 
> Indeed, we have not been good at producing a descent version numbering 
> schema. 
> My position was always this one: the last version should always fit your 
> need. However, some product favored stability when Roassal is used in a 
> commercial setting. 
> We will be more careful when updating the configuration with a proper version 
> number.

Versioning is in fact a complex thing. That’s why I suggest to have a 
brainstorming session during the camp.

Uko

> 
> Cheers,
> Alexandre
> 
> 
>> 
>> On Fri, Jun 5, 2015 at 7:31 PM, Yuriy Tymchuk  wrote:
>> Oh, then it’s my bad. Last time I’ve checked it seemed that it wasn’t 
>> updated for a long time. Maybe I was wrong.
>> 
>> Uko
>> 
>> 
>> 
>>> On 05 Jun 2015, at 18:08, Peter Uhnák  wrote:
>>> 
>>> There sure are, look at ConfigurationOfRoassal2>>version*:
>>> 
>>> and in my baseline I have something like
>>> 
>>> ~~~
>>> spec 
>>> project: 'Roassal2' with: [
>>> spec
>>> className: #ConfigurationOfRoassal2;
>>> versionString: '1.52';
>>> repository: 
>>> 'http://smalltalkhub.com/mc/ObjectProfile/Roassal2/main/' ];
>>> ~~~
>>> 
>>> Peter
>>> 
>>> On Fri, Jun 5, 2015 at 4:37 PM, Yuriy Tymchuk  wrote:
>>> But are there numbered version to refer to?
>>> 
>>> Uko
>>> 
 On 05 Jun 2015, at 16:34, Peter Uhnák  wrote:
 
 
 
 On Fri, Jun 5, 2015 at 3:29 PM, Yuriy Tymchuk  wrote:
 I’m interested in participating. Personally I’d like to talk more about 
 design decisions behind roassal ecosystem, release strategy and so on. 
 Usually when I work with Roassal I have this issue that things are 
 breaking because of rapid changes, or because of the differences between 
 different parts of roassal. Maybe someone is also concerned about this, so 
 we can discuss and maybe improve something…
 
 Yes I am also interested in this, right now I am actually using quite old 
 version (month+) because I didn't have time to keep up. :) (Arguably 90% 
 of my problems were from infamous composite shapes. :))
 
 Peter
 
 Uko
 
> On 04 Jun 2015, at 19:55, Alexandre Bergel  
> wrote:
> 
> Dear Colleagues and Friends,
> 
> We are happy to announce we will organize a CampSmalltalk about the 
> Roassal visualization engine, on _Sunday 12 July_.
> 
> As far as we have seen, the interests are multiple. Here is a list of 
> topics we will happy to work on:
>  - Port of Roassal on VisualWorks
>  - Using Roassal on Gemstone
>  - HTML/JavaScript export
>  - Improving Grapher, our charting library
> 
> If you wish to participate, get in touch with us. Since we will probably 
> have a sponsoring of the event, it would be nice to know how many will 
> attend to ease the logistic and the pizza ordering :-)
> 
> Cheers,
> Alexandre
> --
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel  http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
> 
> 
> 
> 
 
 
 
>>> 
>>> 
>> 
>> 
> 
> -- 
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel  http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
> 
> 
> 
> 

Re: [Pharo-dev] Roassal Camp Smalltalk

[Alexandre Bergel]

> Well at least for me it is certainly not clear what release policy is Roassal 
> following; i.e. if I see a minor version change what to expect, if any BC 
> breaks were introduced, etc. Of course this is extra effort for the person 
> doing it, so it should be taken with care. But there are certainly things to 
> be discussed about this.

Hi Peter,

Indeed, we have not been good at producing a descent version numbering schema. 
My position was always this one: the last version should always fit your need. 
However, some product favored stability when Roassal is used in a commercial 
setting. 
We will be more careful when updating the configuration with a proper version 
number.

Cheers,
Alexandre


> 
> On Fri, Jun 5, 2015 at 7:31 PM, Yuriy Tymchuk  wrote:
> Oh, then it’s my bad. Last time I’ve checked it seemed that it wasn’t updated 
> for a long time. Maybe I was wrong.
> 
> Uko
> 
> 
> 
>> On 05 Jun 2015, at 18:08, Peter Uhnák  wrote:
>> 
>> There sure are, look at ConfigurationOfRoassal2>>version*:
>> 
>> and in my baseline I have something like
>> 
>> ~~~
>> spec 
>>  project: 'Roassal2' with: [
>>  spec
>>  className: #ConfigurationOfRoassal2;
>>  versionString: '1.52';
>>  repository: 
>> 'http://smalltalkhub.com/mc/ObjectProfile/Roassal2/main/' ];
>> ~~~
>> 
>> Peter
>> 
>> On Fri, Jun 5, 2015 at 4:37 PM, Yuriy Tymchuk  wrote:
>> But are there numbered version to refer to?
>> 
>> Uko
>> 
>>> On 05 Jun 2015, at 16:34, Peter Uhnák  wrote:
>>> 
>>> 
>>> 
>>> On Fri, Jun 5, 2015 at 3:29 PM, Yuriy Tymchuk  wrote:
>>> I’m interested in participating. Personally I’d like to talk more about 
>>> design decisions behind roassal ecosystem, release strategy and so on. 
>>> Usually when I work with Roassal I have this issue that things are breaking 
>>> because of rapid changes, or because of the differences between different 
>>> parts of roassal. Maybe someone is also concerned about this, so we can 
>>> discuss and maybe improve something…
>>> 
>>> Yes I am also interested in this, right now I am actually using quite old 
>>> version (month+) because I didn't have time to keep up. :) (Arguably 90% of 
>>> my problems were from infamous composite shapes. :))
>>> 
>>> Peter
>>> 
>>> Uko
>>> 
>>> > On 04 Jun 2015, at 19:55, Alexandre Bergel  
>>> > wrote:
>>> >
>>> > Dear Colleagues and Friends,
>>> >
>>> > We are happy to announce we will organize a CampSmalltalk about the 
>>> > Roassal visualization engine, on _Sunday 12 July_.
>>> >
>>> > As far as we have seen, the interests are multiple. Here is a list of 
>>> > topics we will happy to work on:
>>> >   - Port of Roassal on VisualWorks
>>> >   - Using Roassal on Gemstone
>>> >   - HTML/JavaScript export
>>> >   - Improving Grapher, our charting library
>>> >
>>> > If you wish to participate, get in touch with us. Since we will probably 
>>> > have a sponsoring of the event, it would be nice to know how many will 
>>> > attend to ease the logistic and the pizza ordering :-)
>>> >
>>> > Cheers,
>>> > Alexandre
>>> > --
>>> > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>>> > Alexandre Bergel  http://www.bergel.eu
>>> > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>> >
>>> >
>>> >
>>> >
>>> 
>>> 
>>> 
>> 
>> 
> 
> 

-- 
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Re: [Pharo-dev] Roassal Camp Smalltalk

[Peter Uhnák]

Well at least for me it is certainly not clear what release policy is
Roassal following; i.e. if I see a minor version change what to expect, if
any BC breaks were introduced, etc. Of course this is extra effort for the
person doing it, so it should be taken with care. But there are certainly
things to be discussed about this.

Peter

On Fri, Jun 5, 2015 at 7:31 PM, Yuriy Tymchuk  wrote:

> Oh, then it’s my bad. Last time I’ve checked it seemed that it wasn’t
> updated for a long time. Maybe I was wrong.
>
> Uko
>
>
>
> On 05 Jun 2015, at 18:08, Peter Uhnák  wrote:
>
> There sure are, look at ConfigurationOfRoassal2>>version*:
>
> and in my baseline I have something like
>
> ~~~
> spec
> project: 'Roassal2' with: [
> spec
> className: #ConfigurationOfRoassal2;
> versionString: '1.52';
> repository: 'http://smalltalkhub.com/mc/ObjectProfile/Roassal2/main/' ];
> ~~~
>
> Peter
>
> On Fri, Jun 5, 2015 at 4:37 PM, Yuriy Tymchuk 
> wrote:
>
>> But are there numbered version to refer to?
>>
>> Uko
>>
>> On 05 Jun 2015, at 16:34, Peter Uhnák  wrote:
>>
>>
>>
>> On Fri, Jun 5, 2015 at 3:29 PM, Yuriy Tymchuk 
>> wrote:
>>
>>> I’m interested in participating. Personally I’d like to talk more about
>>> design decisions behind roassal ecosystem, release strategy and so on.
>>> Usually when I work with Roassal I have this issue that things are breaking
>>> because of rapid changes, or because of the differences between different
>>> parts of roassal. Maybe someone is also concerned about this, so we can
>>> discuss and maybe improve something…
>>>
>>
>> Yes I am also interested in this, right now I am actually using quite old
>> version (month+) because I didn't have time to keep up. :) (Arguably 90% of
>> my problems were from infamous composite shapes. :))
>>
>> Peter
>>
>>>
>>> Uko
>>>
>>> > On 04 Jun 2015, at 19:55, Alexandre Bergel 
>>> wrote:
>>> >
>>> > Dear Colleagues and Friends,
>>> >
>>> > We are happy to announce we will organize a CampSmalltalk about the
>>> Roassal visualization engine, on _Sunday 12 July_.
>>> >
>>> > As far as we have seen, the interests are multiple. Here is a list of
>>> topics we will happy to work on:
>>> >   - Port of Roassal on VisualWorks
>>> >   - Using Roassal on Gemstone
>>> >   - HTML/JavaScript export
>>> >   - Improving Grapher, our charting library
>>> >
>>> > If you wish to participate, get in touch with us. Since we will
>>> probably have a sponsoring of the event, it would be nice to know how many
>>> will attend to ease the logistic and the pizza ordering :-)
>>> >
>>> > Cheers,
>>> > Alexandre
>>> > --
>>> > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>>> > Alexandre Bergel  http://www.bergel.eu
>>> > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>> >
>>> >
>>> >
>>> >
>>>
>>>
>>>
>>
>>
>
>

Re: [Pharo-dev] Roassal Camp Smalltalk

[Yuriy Tymchuk]

Oh, then it’s my bad. Last time I’ve checked it seemed that it wasn’t updated 
for a long time. Maybe I was wrong.

Uko


> On 05 Jun 2015, at 18:08, Peter Uhnák  wrote:
> 
> There sure are, look at ConfigurationOfRoassal2>>version*:
> 
> and in my baseline I have something like
> 
> ~~~
> spec 
>   project: 'Roassal2' with: [
>   spec
>   className: #ConfigurationOfRoassal2;
>   versionString: '1.52';
>   repository: 
> 'http://smalltalkhub.com/mc/ObjectProfile/Roassal2/main/ 
> ' ];
> ~~~
> 
> Peter
> 
> On Fri, Jun 5, 2015 at 4:37 PM, Yuriy Tymchuk  > wrote:
> But are there numbered version to refer to?
> 
> Uko
> 
>> On 05 Jun 2015, at 16:34, Peter Uhnák > > wrote:
>> 
>> 
>> 
>> On Fri, Jun 5, 2015 at 3:29 PM, Yuriy Tymchuk > > wrote:
>> I’m interested in participating. Personally I’d like to talk more about 
>> design decisions behind roassal ecosystem, release strategy and so on. 
>> Usually when I work with Roassal I have this issue that things are breaking 
>> because of rapid changes, or because of the differences between different 
>> parts of roassal. Maybe someone is also concerned about this, so we can 
>> discuss and maybe improve something…
>> 
>> Yes I am also interested in this, right now I am actually using quite old 
>> version (month+) because I didn't have time to keep up. :) (Arguably 90% of 
>> my problems were from infamous composite shapes. :))
>> 
>> Peter
>> 
>> Uko
>> 
>> > On 04 Jun 2015, at 19:55, Alexandre Bergel > > > wrote:
>> >
>> > Dear Colleagues and Friends,
>> >
>> > We are happy to announce we will organize a CampSmalltalk about the 
>> > Roassal visualization engine, on _Sunday 12 July_.
>> >
>> > As far as we have seen, the interests are multiple. Here is a list of 
>> > topics we will happy to work on:
>> >   - Port of Roassal on VisualWorks
>> >   - Using Roassal on Gemstone
>> >   - HTML/JavaScript export
>> >   - Improving Grapher, our charting library
>> >
>> > If you wish to participate, get in touch with us. Since we will probably 
>> > have a sponsoring of the event, it would be nice to know how many will 
>> > attend to ease the logistic and the pizza ordering :-)
>> >
>> > Cheers,
>> > Alexandre
>> > --
>> > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>> > Alexandre Bergel  http://www.bergel.eu 
>> > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>> >
>> >
>> >
>> >
>> 
>> 
>> 
> 
> 

Re: [Pharo-dev] Roassal Camp Smalltalk

[stepharo]

I’m interested in participating. Personally I’d like to talk more about design 
decisions behind roassal ecosystem, release strategy and so on. Usually when I 
work with Roassal I have this issue that things are breaking because of rapid 
changes, or because of the differences between different parts of roassal. 
Maybe someone is also concerned about this, so we can discuss and maybe improve 
something…

+1
I coudl also present a bit bloc because Roassal could ported to it :)




Uko


On 04 Jun 2015, at 19:55, Alexandre Bergel  wrote:

Dear Colleagues and Friends,

We are happy to announce we will organize a CampSmalltalk about the Roassal 
visualization engine, on _Sunday 12 July_.

As far as we have seen, the interests are multiple. Here is a list of topics we 
will happy to work on:
- Port of Roassal on VisualWorks
- Using Roassal on Gemstone
- HTML/JavaScript export
- Improving Grapher, our charting library

If you wish to participate, get in touch with us. Since we will probably have a 
sponsoring of the event, it would be nice to know how many will attend to ease 
the logistic and the pizza ordering :-)

Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Re: [Pharo-dev] Roassal Camp Smalltalk

[Peter Uhnák]

There sure are, look at ConfigurationOfRoassal2>>version*:

and in my baseline I have something like

~~~
spec
project: 'Roassal2' with: [
spec
className: #ConfigurationOfRoassal2;
versionString: '1.52';
repository: 'http://smalltalkhub.com/mc/ObjectProfile/Roassal2/main/' ];
~~~

Peter

On Fri, Jun 5, 2015 at 4:37 PM, Yuriy Tymchuk  wrote:

> But are there numbered version to refer to?
>
> Uko
>
> On 05 Jun 2015, at 16:34, Peter Uhnák  wrote:
>
>
>
> On Fri, Jun 5, 2015 at 3:29 PM, Yuriy Tymchuk 
> wrote:
>
>> I’m interested in participating. Personally I’d like to talk more about
>> design decisions behind roassal ecosystem, release strategy and so on.
>> Usually when I work with Roassal I have this issue that things are breaking
>> because of rapid changes, or because of the differences between different
>> parts of roassal. Maybe someone is also concerned about this, so we can
>> discuss and maybe improve something…
>>
>
> Yes I am also interested in this, right now I am actually using quite old
> version (month+) because I didn't have time to keep up. :) (Arguably 90% of
> my problems were from infamous composite shapes. :))
>
> Peter
>
>>
>> Uko
>>
>> > On 04 Jun 2015, at 19:55, Alexandre Bergel 
>> wrote:
>> >
>> > Dear Colleagues and Friends,
>> >
>> > We are happy to announce we will organize a CampSmalltalk about the
>> Roassal visualization engine, on _Sunday 12 July_.
>> >
>> > As far as we have seen, the interests are multiple. Here is a list of
>> topics we will happy to work on:
>> >   - Port of Roassal on VisualWorks
>> >   - Using Roassal on Gemstone
>> >   - HTML/JavaScript export
>> >   - Improving Grapher, our charting library
>> >
>> > If you wish to participate, get in touch with us. Since we will
>> probably have a sponsoring of the event, it would be nice to know how many
>> will attend to ease the logistic and the pizza ordering :-)
>> >
>> > Cheers,
>> > Alexandre
>> > --
>> > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>> > Alexandre Bergel  http://www.bergel.eu
>> > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>> >
>> >
>> >
>> >
>>
>>
>>
>
>

Re: [Pharo-dev] Roassal Camp Smalltalk

[Yuriy Tymchuk]

But are there numbered version to refer to?

Uko

> On 05 Jun 2015, at 16:34, Peter Uhnák  wrote:
> 
> 
> 
> On Fri, Jun 5, 2015 at 3:29 PM, Yuriy Tymchuk  > wrote:
> I’m interested in participating. Personally I’d like to talk more about 
> design decisions behind roassal ecosystem, release strategy and so on. 
> Usually when I work with Roassal I have this issue that things are breaking 
> because of rapid changes, or because of the differences between different 
> parts of roassal. Maybe someone is also concerned about this, so we can 
> discuss and maybe improve something…
> 
> Yes I am also interested in this, right now I am actually using quite old 
> version (month+) because I didn't have time to keep up. :) (Arguably 90% of 
> my problems were from infamous composite shapes. :))
> 
> Peter
> 
> Uko
> 
> > On 04 Jun 2015, at 19:55, Alexandre Bergel  > > wrote:
> >
> > Dear Colleagues and Friends,
> >
> > We are happy to announce we will organize a CampSmalltalk about the Roassal 
> > visualization engine, on _Sunday 12 July_.
> >
> > As far as we have seen, the interests are multiple. Here is a list of 
> > topics we will happy to work on:
> >   - Port of Roassal on VisualWorks
> >   - Using Roassal on Gemstone
> >   - HTML/JavaScript export
> >   - Improving Grapher, our charting library
> >
> > If you wish to participate, get in touch with us. Since we will probably 
> > have a sponsoring of the event, it would be nice to know how many will 
> > attend to ease the logistic and the pizza ordering :-)
> >
> > Cheers,
> > Alexandre
> > --
> > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> > Alexandre Bergel  http://www.bergel.eu 
> > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
> >
> >
> >
> >
> 
> 
> 

Re: [Pharo-dev] Roassal Camp Smalltalk

[Peter Uhnák]

On Fri, Jun 5, 2015 at 3:29 PM, Yuriy Tymchuk  wrote:

> I’m interested in participating. Personally I’d like to talk more about
> design decisions behind roassal ecosystem, release strategy and so on.
> Usually when I work with Roassal I have this issue that things are breaking
> because of rapid changes, or because of the differences between different
> parts of roassal. Maybe someone is also concerned about this, so we can
> discuss and maybe improve something…
>

Yes I am also interested in this, right now I am actually using quite old
version (month+) because I didn't have time to keep up. :) (Arguably 90% of
my problems were from infamous composite shapes. :))

Peter

>
> Uko
>
> > On 04 Jun 2015, at 19:55, Alexandre Bergel 
> wrote:
> >
> > Dear Colleagues and Friends,
> >
> > We are happy to announce we will organize a CampSmalltalk about the
> Roassal visualization engine, on _Sunday 12 July_.
> >
> > As far as we have seen, the interests are multiple. Here is a list of
> topics we will happy to work on:
> >   - Port of Roassal on VisualWorks
> >   - Using Roassal on Gemstone
> >   - HTML/JavaScript export
> >   - Improving Grapher, our charting library
> >
> > If you wish to participate, get in touch with us. Since we will probably
> have a sponsoring of the event, it would be nice to know how many will
> attend to ease the logistic and the pizza ordering :-)
> >
> > Cheers,
> > Alexandre
> > --
> > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> > Alexandre Bergel  http://www.bergel.eu
> > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
> >
> >
> >
> >
>
>
>

Re: [Pharo-dev] Roassal Camp Smalltalk

[Yuriy Tymchuk]

I’m interested in participating. Personally I’d like to talk more about design 
decisions behind roassal ecosystem, release strategy and so on. Usually when I 
work with Roassal I have this issue that things are breaking because of rapid 
changes, or because of the differences between different parts of roassal. 
Maybe someone is also concerned about this, so we can discuss and maybe improve 
something…

Uko

> On 04 Jun 2015, at 19:55, Alexandre Bergel  wrote:
> 
> Dear Colleagues and Friends,
> 
> We are happy to announce we will organize a CampSmalltalk about the Roassal 
> visualization engine, on _Sunday 12 July_. 
> 
> As far as we have seen, the interests are multiple. Here is a list of topics 
> we will happy to work on:
>   - Port of Roassal on VisualWorks
>   - Using Roassal on Gemstone
>   - HTML/JavaScript export
>   - Improving Grapher, our charting library
> 
> If you wish to participate, get in touch with us. Since we will probably have 
> a sponsoring of the event, it would be nice to know how many will attend to 
> ease the logistic and the pizza ordering :-)
> 
> Cheers,
> Alexandre
> -- 
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel  http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
> 
> 
> 
> 

Re: [Pharo-dev] Roassal Camp Smalltalk

[Peter Uhnák]

Hi Alex,

is it possible to add some discussion about stuff we did in roassal for
dynacase to the list?
Because I feel there is some duplication effort and also we could probably
contribute some stuff we did back. Or perhaps even more general discussion
about using roassal for more dynamic and modifiable visualizations/modeling
(e.g. composite shapes, bendable lines, resizable boxes, etc.)

Peter

On Thu, Jun 4, 2015 at 7:55 PM, Alexandre Bergel 
wrote:

> Dear Colleagues and Friends,
>
> We are happy to announce we will organize a CampSmalltalk about the
> Roassal visualization engine, on _Sunday 12 July_.
>
> As far as we have seen, the interests are multiple. Here is a list of
> topics we will happy to work on:
> - Port of Roassal on VisualWorks
> - Using Roassal on Gemstone
> - HTML/JavaScript export
> - Improving Grapher, our charting library
>
> If you wish to participate, get in touch with us. Since we will probably
> have a sponsoring of the event, it would be nice to know how many will
> attend to ease the logistic and the pizza ordering :-)
>
> Cheers,
> Alexandre
> --
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel  http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
>
>
>