Le 04/09/2013 11:27, Marcus Denker a écrit :
On Sep 4, 2013, at 10:18 AM, Goubier Thierry <[email protected]> wrote:
But it is clear that this is a fine line: one persons fix is the others persons
bug, so we tend to be conservative.
But nevertheless, all show-stopping bugs should be fixed.
In general: It is *a lot* of work, and it is hard to get right in all cases.
But considering that: do we really do that badly?
I can undestand that.
I also understand that you need 3.0 to be declared unstable to be able to make
the necessary improvements in it.
But this has the following consequences for non-core development, say SmaCC for
example: 2.0 is the platform for unstable, 1.4 is where your stuff is stable
(2.0 if you're lucky), and 3.0 is don't develop until it has reached a
sufficient level of maturity. I will do things on SmaCC in the near future, but
not on 3.0.
What is a solution other than stopping development and declaring Pharo as
finished as it is?
No. Just admit that you have productions 1.4 (and maybe 1.3) hanging around,
that 2.0 is the main development platform for Pharo users, 3.0 is where you
make interesting stuff.
Yes, and the whole moving forward vs. stability is a real, classical tragedy: there is no
solution other than minimizing the pain. Whatever we do it will be wrong. The only
"solution" is
to stop doing, then the pain stops but there will be no future.
You're arguing the extreme there :)
Forced march to 3.0 seems difficult and counter productive to me, that's
all.
e.g. imagine we would say: "Yes, you convinced us to stop. Pharo is finished".
Then someone else would develop "SuperSmalltalk" which is more or less what
Pharo 6 would have been, and it's even released around that time.
What will the reactions of the Pharo users be?
-> "I will not use it because I argued that Pharo is perfect and finished and I now
will support those people who gave up on their future for my needs 4 years ago!"
?
I'm sure you are good enough to convince people to switch to 3.0 even if
2.0 has no bugs. And there will still be new things for 4.0, 5.0, 6.0, ...
Many things in store for 3.0 are very interesting and motivating; it's
just that, given the state of things, I have to wait and get 2.0 fixed
as well as possible. And get ready to transition to 3.0 as smoothly as
possible (and repeat for the next version)...
And that Pharo users are at least one version behind you, and that they would
like a bit of smoothness in the way it evolves... 3.0 gives directions; but a
bit of backport to help with the transition would be, what, just friendly to
your users.
For example, for things I am aware of:
- backport ensureDelete to 2.0
- backport the replacement of Keymapping on:do:
Ok, then lets move forward with these. In the grand scheme of things, this is
not that much work to fix.
You have 2.0 users who have things to say and who are able to correct things as well;
don't belittle them by saying "All software development should be done on 3.0"
[Camillo Bruni].
Yes, there are many people in Pharo and everyone has their own opinion, and
this is good.
But why would we maintain 2.0 if nobody is suppose to use it?
That's the point :)
Thierry
--
Thierry Goubier
CEA list
Laboratoire des Fondations des Systèmes Temps Réel Embarqués
91191 Gif sur Yvette Cedex
France
Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
