Re: [Simulavr-devel] Plan for make a first release of simulavr

[Klaus Rudolph]

Joerg Wunsch wrote:
> As Petr Hluzín wrote:
> 
>> My objection is still that the new simulavr is incomplete (the
>> existing features would have use for some polishing).
> 
> But well, this will always be the case.  In my opinion, the release
> is *long* overdue.

I would like to have a complete set of tools in a "suite release". I
expect (as a normal user, not as tool developer) that I could download
all the tools and get them to work. The minimum I expect is, that I
could get a defined set of releases to work. Actually I could not find a
info which version of binutils run with which compiler and debugger and
which revision number of simulavr.

My last try to get binutils/gcc/gdb/simulavr/ddd to work was not very
successfull. Maybe the head of simulavr is actually fixed, but I don't
know. avrlibc was broken with gcc4.7, gdb > 7.01 is not working with
simulavr and other tools (jtag debugging) and so on.

Maybe it is not a good point to freeze for a release.

> 
>> If the polishing
>> is delayed, it will break people's stuff in next release.
> 
> Then, make this release 1.0, and if the next release really breaks to
> many things, name it 2.0.  This still leaves the option to continue
> 1.x on a branch if there's enough demand.

I personally prefer a lot of releases with lesser changes.

> 
>> Specially, the Python and TCL interface exposes all internals,
>> therefore any change may break some script.
> 
> How many people are really using that already?  Sometimes, it's just
> as easy as mentioning these interfaces as "preliminary".  I think most
> of those who really want a released software actually want to use the
> normal CLI of the simulator, and the GDB interface on top of that.

I use TCL a lot as setup for my regression test of my projects. But my
last try to get the actual simulavr repository to run was not
successful, so I stopped before using my regression test.

> 
> One of the F/OSS basic rules is "release frequently".
> 
>> A version 2.0.0 would suggest some kind of revolution. The
>> implementation language changed from C to C++ [...]

That was long long ago ;)

> 
> But that would already be covered well enough by the transition
> from 0.1 to 1.0.
> 

Nice discussion... maybe 0.2 is better :-)

Regards
 Klaus