It all sounds good.
My concern is stability. Not just crashing but functionality. Here is off the top of my head.
-
draw tool operation. Undo and redo are not at the best with replacing the whole molecule. Personally I’d like to serialize the PrimitiveList class so the selective rendering is restored in the engines when the whole molecule gets replaced.
-
surfaces and orbitals are good?
-
general bug fixes. We’ve been adding a LOT of functionality and totally pumps me up for the release but there are a LOT of open bugs. There are probably a lot that need fixing. The auto-opt tool is creating and destroying a thread at each step. Something is wrong in the code. Run it in gdb to see. Anyways this is just one example. I’m fearing there are some other similar problems.
-
do we want to move extensions to libavogadro? If we don’t I’d like to see Extensions take a text stream rather than a QMessageBox or whatever they’re taking now.
-
optimization still gives ‘nan’ values and man, that is annoying! Anyway we can fix this? This goes back to open bugs and my next point.
-
Anything that makes the molecule disappear NEEDS to be fixed before release.
But with all that said, there is nothing like a release to really expose our bugs. I’d just like to see a lot of the bugs that we have reported get fixed before a release. We need a feature freeze or make a branch again. Also, I’m not going to have time to make a windows release by that date.
As for a 1.0 I really think we need our own format. Most of it (I think) can be done using a filter on QSettings which is really what I think we should do for most of it since I’ve already implemented that for the engines. But again I need to serialize that data for the engines at some point. I haven’t thought about it too much but as always I want to reduce functions in the Engine, Tools, Extensions class.
Also, if we’re seriously thinking about maintaining ABI compatibility I am cautious to take our time because I think we have a good API but we rely so heavily on plugins (virtual functions) that those will need to be solid. I think we’re very close but its somewhat scary to say our plugin API is solid. If we’re not thinking ABI compat then I’m ok with releasing everyday.
Donald
-----Original Message-----
From: “Marcus D. Hanwell” marcus@cryos.net
Date: Tue, 19 Feb 2008 21:16:18
To:avogadro-devel@lists.sourceforge.net
Subject: [Avogadro-devel] Avogadro 0.6 - time for another release!
Hi,
I thnk we are well past due for a new release. I also think we have added far
too many new features between releases and our next release should be
numbered 0.6 to signify that we are certainly approaching a stable and very
useful cross-platform molecular editor.
I just made a post about the new orbital support I got in over the weekend,
http://blog.cryos.net/archives/173-Avogadro-New-Orbital-Support-and-Gaussian-Cube-Format.html
I hope people like the screenshots, I am really pleased with it but there is
still more to do. Surface support and orbitals were two major features we
felt were lacking before we got to 1.0. I think the last big one is scripting
support to be honest.
So bearing in mind I would love to get another release out within two weeks
what do people feel we need to get in before that release? What are the major
bugs that need fixing and small features we should finish or try to
implement? I think it is important that we get wider testing of Avogadro by
making regular releases and I think bumping our version number also signifies
our rapid progress and approach of a stable release.
I propose that we release Avogadro 0.6 on 29 February as we have so few 29ths
in February. So get in your requests, file your blocker bugs and lets get a
release ready!
Thanks,
Marcus
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft® Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
Avogadro-devel mailing list
Avogadro-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/avogadro-devel