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

[Petr Hluzín]

On 4 January 2012 16:46, ThomasK <address@hidden> wrote:
> Hi,
>
> after some questions about building a released version of simulavr and after
> many months of development, :-) (sure, last time it was only Petr, which has
> commited some work) it's time to create a first release. I'll start this in
> the beginning of february, e.g. create a release branch for this release,
> build the release, build documentation and so one. Update website and upload
> released files.

It would be nice to ask other developers about their opinion :-). We
discussed the release idea in [1]. I admit I missed Joerg Wunsch's and
your proposal [2], my fault.

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.

(In long term I want to make simulavr easier to use. People in F/OSS
generally do not understand why it is good and they will object to
changes that would make users spend less time & mental effort forcing
tool to do its job and allow them to spend more time on
fun/interesting/job problems. Release early, release often, get
stuck.)

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

As said in [1] I am OK with some kind of technology-preview or
taste-what-is-being-cooked-in-kitchen tarball. Preferably doing it
silently.

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.

The release procedure you suggest is good - except I would rather not
do a full-blown release, as explained above.

>
> So, if somebody is developing functionality and want's to finish it in this
> time, should write this on the list.

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.

>
> The last released version for the "old" simulavr was 0.8.x. So I could
> choose 1.0.0 for this release, but maybe it's better to choose 2.0.0 to have
> a better separation to "old" simulavr. What's better?

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.

[1] http://lists.nongnu.org/archive/html/simulavr-devel/2011-05/msg00014.html
[2] http://lists.nongnu.org/archive/html/simulavr-devel/2011-12/msg00004.html

-- 
Petr Hluzin