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

[ThomasK]

Hi,

> My objection is still that the new simulavr is incomplete (the
> existing features would have use for some polishing). If the polishing
> is delayed, it will break people's stuff in next release.

Agree! I think, you will have 2 times more ideas for improvements than 
developers. So it wouldn't be finished anymore. :-)

But I think, there are many people, which want to get a "released" 
software. Even if there are all planned features or not. Just to have a 
fixed state and maybe fixing some urgent errors above this state. And 
not a "moving target" as a continous development naturally is.

This should not stop development! This should give a fixed state with a 
tar ball, built images for Linux and (as Eric asked) for Windows and 
Mac, documentation files. To use it without  building all the stuff forself.

But: if we don't do that, we wouldn't do that in any time later!

> Specially, the Python and TCL interface exposes all internals,
> therefore any change may break some script.

Agree! But for this it's also a good idea to have a released state, 
which gets only necessary bugfixes. So people know, with which release 
this was working and with which not. And we can report interface changes 
in a changelog.

> In future I might commit to separate branch or different repository.
> This would allow doing releases from trunk without incomplete features
> of mine, however this would still release incomplete features in
> trunk.

Separate branch is a good idea, if you want to show others your changes 
for comment or test. But not only, you are free to upload such branch to 
savannah or not! You can create a branch only in your local repo for you 
without uploading. For example for a long running change. For a short 
bugfix in master branch you have to stash your currently not commited 
work, switch to the other branch, make the bugfix, push it up, switch 
back to your branch, get out the stashed work and you are back again.

> I have a partial implementation of some ideas/features but I have no
> idea if I will finish them in February or later. I have them both
> locally and committed in trunk - the trunk stuff is ready for
> developers but not for users.

Hm... "trunk" means master branch? I think, I'll start in february with 
creating the release branch from current master branch an push it up to 
savannah. Means, that if your changes do not influence normal work or 
break simulavr, (as Joerg wrote CLI and gdb server) then it should be 
ok. Maybe deactivate it, if this is the easiest way to avoid problems.

Then, in a second step, I'll create image for linux, creating 
documentation and so one. Btw. I should be able to create a windows 
image, but only with cygwin/msys. If somebody is able to create images 
for Mac or with VS for windows, then send it to me! (or push it up to 
savannah and write me about this) Last step will be updating website.

> A version 2.0.0 would suggest some kind of revolution. The
> implementation language changed from C to C++ but that is not visible
> to users. Users will only see the the new simulavr is
> feature-incompatible. Therefore I am slightly more in favor of 1.0.0.
> I have no strong feelings in this regard, though.

Ok, with the response from Joerg and Eric too, this release will be 
1.0.x (x means bugfixes, if this is necessary)

And maybe I'll add some text about the state of this released version, 
especially as Joerg proposed, that TCL and PY are preliminary and so one.