1.2 goals [Re: SmartEiffel open Edition - what would be the goals?]

On Thu, 2005-05-26 at 16:24 +0100, Roger Browne wrote:

> I can't really embrace Daniel's idea of repeating history by developing
> SmartEiffel 1.2 as a transition between 1.1 and 2.x. The SE team has
> done several man-years of development between 1.1 and 2.x. Why repeat
> any of that work? If we want the fruits of that development, we should
> just keep using 1.1 until we are able to upgrade to 2.x. If we don't
> want the fruits of that development, we can continue to maintain 1.1.
> To do some of the same work over again seems like an unnecessary
> duplication of effort. But maybe I misunderstand Daniel's goals.

I think you did. I'm not planning to replicate much of 2.x work
(although some of that will be needed), and I want everybody to be able
to have the fruits of the work done by the SE team for 2.x

I started to think about this project when trying to take that fruits
myself. I have written a lot of Eiffel code, some of it is publicly
available, mostly libraries I have found useful.

When 2.0 came out, I noticed that some of the new features were
attractive, and tried to use them. But my libraries didn't compile in
2.x. And to upgrade them, I would have needed to break compatibility
with 1.1. So my choices were to stay in 1.1 (and be left with an
unmantained release), or to go to 2.x, and force the same choice to my
users. In some cases it was even harder, because I depended on a 3rd
party library which worked only on 1.1

So moving to 2.0 (when you have an investment in 1.1 code) is a lot of
effort and harsh to my users. Staying in 1.1 is an evolutionary
dead-end. What I would have liked, is an 1.2 release that is not a pain
to migrate to (from 1.1), where I can port my code, and made in a way
that I can code for it and 2.x at the same time.

That release never existed (and probably would have been impossible
without perfect future foresight before 2.x was released).

So I'm writing it. I have the advantage of having perfect foresight
because 2.1 is around and I know what it does and what it does not. But
if 1.2 is successful, library developers should be able to go to 1.2,
make their work compatible with 2.x gradually, and then move to 2.x when
2.x has enough community and libraries to make it a safe option to move
to.

So, I will consider that 1.2 was successful, if some months (or a few
years?) after its release, nobody is using it and is using 2.x
instead :)

> An interesting question is: what should we do if we want to continue to
> develop SmartEiffel, but with different priorities than the SE research
> team? What would the priorities be for a community-developed industrial-
> strength SmartEiffel? Here are my suggestions:

Note that several goals of my project are similar to yours. And others
are compatible.

I'm doing it to help focus the community on SE. You might be doing it to
fork away (which I consider harmful to the already weak Eiffel
community). Anyway, I think we could share a lot of work.

* You mention correctness. That's a matter of following and closing
bugs. SE and SE1.2 have bugtrackers, and SE12 plans to have an open
model so a lot of people will be able to help closing them
* Compatibility: As I said, 100% compatibility with 1.1 is a primary
goal, and adding things from 2.x and ISE a secondary one (secondary does
not mean "not important" here, it means "second most important"). And
note that I'm starting from 1.1, as you propose :)
* Interoperability: I have no plans to work on that, but that doesn't
mean I'll reject contributions in this sense. However, I will prefer to
introducing these patches as they are accepted in mainstream SE. If the
SE team is rejecting them for no valid reasons, we can rediscuss this
way of doing this, but I will make all my effort to be a friendly
branch, and to not go away from the official SE (to avoid splitting the
community. I will tire all of you repeating this ;-) )
* Performance: same as above
* Productivity: I think making an effort towards compatibility allows
3rd parties to invest work on this. Tools like that are useful, but
there is no need to force them on the compiler writers (specially at
open source world, you can note that compilers and tools are often made
by separate people)
* Simplicity and mantainability: I guess I will be forced to do that,
given that those qualities will allow me to get all the help I need :)

> Should we fork SmartEiffel 1.1 with a set of goals similar to these?

You are able to fork, of course; as I said 42 times before ;-) , I think
that will be counterproductive. Even if you plan to do that (I can't
stop you :) ) consider working with SE1.2; we share a lot of goals from
the code (and I promise you'll have an open model, and you already have
an open code repository).

	Daniel

PS: roger, sorry about the duplication, I answered by mistake to your personal email address