Le 05/09/2013 22:04, Stéphane Ducasse a écrit :
Who says that? We always said that we will back-port all imported fixes to 2.0.
We will not back-port *everything*, especially
not improvements that are not fixes, because then there would be no difference
between Pharo3 and Pharo2 (and these
tend to introduce new problems, making it very hard to stabilize).
Are you afraid that by improving Pharo2 on a production-level, you would remove
incentives to move to pharo3?
No just that we do not want to stop 3.0. Because changing 20 will introduce bug
we are 100% convinced about that.
The system is still not in a situation where changes are simple and with
limited impact.
As you said, 2.0 has bugs. Look, at one point, we even had a 2.5 in the
works (who did it, already? Sean? Sven?).
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.
I'm OK with that. It's just that I'm updating a fix for a bug on both Pharo2
and Pharo3 by myself just to be able to open a file browser and get correct
file permissions.
I'm also unable to be sympathetic to a situation where I have two versions of a
code just because when deprecating ensureDeleted in 3.0, nobody thought usefull
to backport ensureDelete so that we could ensure that code using ensureDelete
could work on both versions.
This is simple nobody told us. Open an issue and tag it 20 + code and it will
be in the batch of 2.0.
I'll do.
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,
No it is not 2.0 is stable. We have production code with it. Now it is not bug
free and 1.4 is far from bug free. It is just that you do not get
touched by these bugs.
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.
this is a mistake to me. Because if you discover bugs we will fix them. Now if
you wait one year to move to 3.0 we will be working on 4.0 and
the story will never ends.
And there I can only disagree with you.
* I do want you on an unstable Pharo, something moving and changing fast
to be able to aim for the sky and bring me a smile for what tomorrow
will bring me...
* I want a stable Pharo, because this is where my work takes place, and
there bugs should really get fixed...
* I want old stable Pharo(s), because, if my work goes into production,
it may stay there for years.
* And I want a nice path from today's stable to the next stable to be
able to port my code as soon as possible (for example, we did OSProcess
this time... but I believe there is a chance this work will have to be
done again before 3.0 is released ;))
Insisting for 3.0 based developpement means I require additional code to
the core: OSProcess, FileTree, GitFileTree, SmaCC... Maintaing those for
3.0 is extremely difficult, with very disruptive changes coming often.
And one get tired of complaining; at one point I just open a bugfix,
create a slice and add a line to my image building makefiles to load the
bugfix because bickering about whether it should be integrated or not
isn't worth the time spent on it.
So my suggestion would be more like this: 2.0 stable, 3.0 beta (freeze),
and 4.0 alpha (experimental), and maybe different teams for handling
each of those (and releases on a six months basis?).
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
