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