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 <stepharo@free.fr> 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... 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 <yuriy.tymchuk@me.com> wrote:
On 08 Jun 2015, at 18:22, Alexandre Bergel <alexandre.bergel@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 <yuriy.tymchuk@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 <i.uhnak@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 <yuriy.tymchuk@me.com> wrote: But are there numbered version to refer to?
Uko
On 05 Jun 2015, at 16:34, Peter Uhnák <i.uhnak@gmail.com> wrote:
On Fri, Jun 5, 2015 at 3:29 PM, Yuriy Tymchuk <yuriy.tymchuk@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 <alexandre.bergel@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 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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.