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
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 steph...@free.fr wrote:
Hi Peter
Definitively. Having stable API is key for
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 i.uh...@gmail.com wrote:
Since I've already run into second thing in agile visualization book that is
outdated (RTArrow, which was some time
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
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
On 08 Jun 2015, at 18:22, Alexandre Bergel 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
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
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
But are there numbered version to refer to?
Uko
On 05 Jun 2015, at 16:34, Peter Uhnák i.uh...@gmail.com wrote:
On Fri, Jun 5, 2015 at 3:29 PM, Yuriy Tymchuk yuriy.tymc...@me.com
mailto:yuriy.tymc...@me.com wrote:
I’m interested in participating. Personally I’d like to talk more about
On Fri, Jun 5, 2015 at 3:29 PM, Yuriy Tymchuk 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
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
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 i.uh...@gmail.com wrote:
There sure are, look at ConfigurationOfRoassal2version*:
and in my baseline I have something like
There sure are, look at ConfigurationOfRoassal2version*:
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/' ];
~~~
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
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
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
16 matches
Mail list logo
