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 _______________________________________________ Simulavr-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/simulavr-devel
