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
On Sep 4, 2013, at 10:18 AM, Goubier Thierry <thierry.goubier@cea.fr> 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.
>
to stop doing, then the pain stops but there will be no future.
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!"
Ok, then lets move forward with these. In the grand scheme of things, this is not that much work to fix.
?
> 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:
Yes, there are many people in Pharo and everyone has their own opinion, and this is good.
>
> 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].
>
But why would we maintain 2.0 if nobody is suppose to use it?
�� �� �� �� Marcus