I’m going to throw out a tentative schedule. Since this is a 0.1.0
(essentially beta) release i’m not going to worry about feature freeze
and bug fixes. Just going to say we’re freezing and unless there are
any major bugs we work on building packages.
2007-05-11: 0.1.0 Code Freeze (Tagged), Begin package building.
2007-05-18: Full Release including binary packages for OSX and Windows
I just added the Undo/Redo framework. I’m going to work on pasting of
cartesian coordinates tomorrow. I’m not sure what problems I’m going to
run into but i’m going to leave it up to Benoit to make me happy
worrying about how to orient the pasted stuff. I implemented the same
thing in Ghemical but the only problem was that the optimize engine
didn’t take care of the situation where you pasted twice on top of each
other and had a divide by 0.
On May 3, 2007, at 3:17 AM, Donald Ephraim Curtis wrote:
2007-05-18: Full Release including binary packages for OSX and Windows
I think one important question is whether the OS X and Windows
binaries say “install Qt 4.2.x first” or include it. Considering this
is a beta release, I’d go with having people install Qt first. It
will cut down on the size of download significantly.
didn’t take care of the situation where you pasted twice on top of
each
other and had a divide by 0.
That “should” be fixed in the Open Babel force field code. If not,
it’s a bug and I can fix it. (It was much, much harder to figure out
the fix in the Ghemical codebase.)
On May 3, 2007, at 4:14 PM, Donald Ephraim Curtis wrote:
problems running Avo, and give up. In someways i think because
it’s a
beta it might be even more important to package it all.
Point taken. Yes, it’s possible to have a “metapackage” containing
the Qt packages, Avogadro, and Open Babel. It’s basically what I do
for ChemSpotlight.
I’ll see if I can figure out the smallest subset of Qt libraries.
One nice thing about the Avogadro.app bundles is that they can
include libraries and frameworks. (This is one way Apple escapes
library incompatibility issues.) Google does this with Google Earth
– it includes Qt inside “Google Earth.app”
I was just wondering if people would be intimidated downloading a
40MB installer for a beta project.
Well, on windows it’s not a problem because i just copy the QtGui.dll /
QtOpenGL.dll / *.dll into the executable directory and they are
automatically loaded.
For OSX, is there anyway we could just make our own QT package that only
includes the libraries that we need in the same locationg that QT
installs them? I mean, it would just be convenient if people don’t have
to worry about that kinda stuff. The other possibility that they talk
about in some sites ( I think the QT site mentions it) is to just copy
the precompiled libraries right into the bundle. I really think it’d be
nice to have a bundle rather than existing in /usr/local/* or whatever.
But you’re right, this is beta, i think that’s ok to require them to
download QT. It’d just be nice if we could, at some point, figure out
either a all-inclusive install (with small size) or self contained .app
I need to get a mac so i can figure this stuff out.
On May 3, 2007, at 3:17 AM, Donald Ephraim Curtis wrote:
2007-05-18: Full Release including binary packages for OSX and Windows
I think one important question is whether the OS X and Windows binaries say
“install Qt 4.2.x first” or include it. Considering this is a beta release,
I’d go with having people install Qt first. It will cut down on the size of
download significantly.
didn’t take care of the situation where you pasted twice on top of each
other and had a divide by 0.
That “should” be fixed in the Open Babel force field code. If not, it’s a
bug and I can fix it. (It was much, much harder to figure out the fix in the
Ghemical codebase.)
On linux it looks like the QT runtime is only 15 megs. If we could
somehow build a QT runtime package, that would not be that much to
install. Isn’t there a mac-designated location for libraries like the
C:\windows\system32 directory on windows? /Developer/libraries or
something?
Also, what about creating two packages, one that is packaged with Qt and
one that is not.
My biggest concern is that I want a one-click install. Even though it’s
beta, i want it to get exposure to chemists and i don’t want them to get
frustrated right off the bat having to worry about dependancies and
stuff. If we only provide one and have a line “you must download Qt”,
some people (and i’ve been guilty of this before) will skip it, having
problems running Avo, and give up. In someways i think because it’s a
beta it might be even more important to package it all.
Donald
(Thu, May 03, 2007 at 01:58:00PM -0600) Donald Ephraim Curtis d@milkbox.net:
Well, on windows it’s not a problem because i just copy the QtGui.dll /
QtOpenGL.dll / *.dll into the executable directory and they are
automatically loaded.
For OSX, is there anyway we could just make our own QT package that only
includes the libraries that we need in the same locationg that QT
installs them? I mean, it would just be convenient if people don’t have
to worry about that kinda stuff. The other possibility that they talk
about in some sites ( I think the QT site mentions it) is to just copy
the precompiled libraries right into the bundle. I really think it’d be
nice to have a bundle rather than existing in /usr/local/* or whatever.
But you’re right, this is beta, i think that’s ok to require them to
download QT. It’d just be nice if we could, at some point, figure out
either a all-inclusive install (with small size) or self contained .app
I need to get a mac so i can figure this stuff out.
On May 3, 2007, at 3:17 AM, Donald Ephraim Curtis wrote:
2007-05-18: Full Release including binary packages for OSX and Windows
I think one important question is whether the OS X and Windows binaries say
“install Qt 4.2.x first” or include it. Considering this is a beta release,
I’d go with having people install Qt first. It will cut down on the size of
download significantly.
didn’t take care of the situation where you pasted twice on top of each
other and had a divide by 0.
That “should” be fixed in the Open Babel force field code. If not, it’s a
bug and I can fix it. (It was much, much harder to figure out the fix in the
Ghemical codebase.)
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/
Are you guys interested in doing some more dev (fixing big bugs) and
releasing another release (0.1.1) in like 2 weeks / 1 month? I would
really like to fix some undo/redo bugs, update some interfaces and fix a
few context problems to make Avo a little more solid?
Are you guys interested in doing some more dev (fixing big bugs) and
releasing another release (0.1.1) in like 2 weeks / 1 month? I would
really like to fix some undo/redo bugs, update some interfaces and fix a
few context problems to make Avo a little more solid?
I also wondered about this for Kalzium… Marcus and Benoit: Are we
going to use 0.1.x and be happy with it or trunk/ ? I guess that it
might be easier to stick with 0.1.x in which case a bugfix-branch
would be great…
On May 15, 2007, at 1:42 PM, Donald Ephraim Curtis wrote:
Are you guys interested in doing some more dev (fixing big bugs) and
releasing another release (0.1.1) in like 2 weeks / 1 month?
The thing is, I suspect with feedback from users and the current pace
of progress, we could easily call it 0.2.0 in the almost the same
timeframe. If we’re going for a second beta (with that timeframe), we
could also switch to Qt 4.3 and use the new widgets.
I mean, what people notice for “major” updates is not really the bug
fix, but “big features.” For example, I want to add in an “insert
from file” extension, the bits I discussed for displaying unit cells,
etc.
If Kalzium is going to stick to 0.1.x, then it makes sense to keep a
long-lived branch. But otherwise, I think we should plow on with a
new release.
Are you guys interested in doing some more dev (fixing big bugs) and
releasing another release (0.1.1) in like 2 weeks / 1 month? I would
really like to fix some undo/redo bugs, update some interfaces and fix a
few context problems to make Avo a little more solid?
I also wondered about this for Kalzium… Marcus and Benoit: Are we
going to use 0.1.x and be happy with it or trunk/ ? I guess that it
might be easier to stick with 0.1.x in which case a bugfix-branch
would be great…
I think ideally we will stick with a tagged release. So yeah a bug fix branch,
or a 0.2 release just before the feature freeze would work well (assuming
there wasn’t too much to port).
There are a few bits I was hoping to get done pretty soon too although my time
in the next two weeks is quite limited I’m afraid - work commitments.
We need to release a 1.0.2, which is sorely needed. Let’s gather the current state of the 1.0 branch, see if there are obvious fixes, and release a 1.0.2 “real soon now.”
We should aim to branch 1.1 with the current trunk soon – IMHO around the end of February with the aim of a March or April release of 1.1.0. We have a LOT of good new features which no one sees. It’s been almost 18 months since 1.0 was released… For example, we now have an extremely easy to use AIM analysis method.
I mention this because Marcus just said he learned a lot to apply to an Avogadro 2.0 release. Konstantin also had some library reorganization which would be more appropriate to a 2.0 release, and we’re seeing other possible changes like Eigen 3.0. So I think it’s in the best interest of the project to push hard on getting releasing soon and releasing often again.
Keep in mind that new users and new developers are attracted to projects when they see new releases.
We need to release a 1.0.2, which is sorely needed. Let’s gather the current state of the 1.0 branch, see if there are obvious fixes, and release a 1.0.2 “real soon now.”
I have been looking at the patches distros have today actually.
Several fixes have been applied, SIP being one of the more obvious
things. I also came across a few comments saying that master was
unstable, and I will look into that.
We should aim to branch 1.1 with the current trunk soon – IMHO around the end of February with the aim of a March or April release of 1.1.0. We have a LOT of good new features which no one sees. It’s been almost 18 months since 1.0 was released… For example, we now have an extremely easy to use AIM analysis method.
There are quite a few new bugs too. It would be good to get some of
the crashers fixed, and I am already working on tracking some of them
down. I would like to build up a list of blocker bugs and handle them
ASAP.
I mention this because Marcus just said he learned a lot to apply to an Avogadro 2.0 release. Konstantin also had some library reorganization which would be more appropriate to a 2.0 release, and we’re seeing other possible changes like Eigen 3.0. So I think it’s in the best interest of the project to push hard on getting releasing soon and releasing often again.
I talked with Benoit, and he let me know that the data structures we
expose in our API are unchanged, but bumping our requirement would be
simplest.
Keep in mind that new users and new developers are attracted to projects when they see new releases.
Yes, I see rumblings from distros. I would like to push out a 1.0.2 ASAP too.
We need to release a 1.0.2, which is sorely needed. Let’s gather the current state of the 1.0 branch, see if there are obvious fixes, and release a 1.0.2 “real soon now.”
Surely. However, one unresolved crash case with H bonds remains unfixed
We should aim to branch 1.1 with the current trunk soon – IMHO around the end of February with the aim of a March or April release of 1.1.0. We have a LOT of good new features which no one sees. It’s been almost 18 months since 1.0 was released… For example, we now have an extremely easy to use AIM analysis method.
I’d like to propose an idea about alternative version numbering. Currently we agreed to consider even minor releases (1.0.x, 1.2.x, etc.) as “stable”, and odd as “unstable”
Since our release schedule changed a lot since 0.9.x period, I think Mesa-like version policy is more appropriate for us: release “1.1.0” as unstable, and then stabilize it in patch releases keeping ABI stable. When we consider 1.1.1 or 1.1.2 “stable”, 1.0 should be deprecated
About 2.0: I can imagine Avogadro 1.2 running libavogadro 2.0, if “user”-side changes are not serious enough for new major release of application
Right, and AFAICT, that’s already part of the 1.0 branch, correct? I’m looking for fixes which aren’t part of the 1.0 branch yet, but should be.
(And along the way, we should make sure anything which is on the 1.0 branch since 1.0 and 1.0.1 are integrated into trunk.)
Right, and AFAICT, that’s already part of the 1.0 branch, correct? I’m looking for fixes which aren’t part of the 1.0 branch yet, but should be.
(And along the way, we should make sure anything which is on the 1.0 branch since 1.0 and 1.0.1 are integrated into trunk.)
I can reproduce the crash, so I’ll work on it.
Things like the SIP patch are widely patched in distros, so that patch
was about integrating many of their fixes. That will be applied to
both branches, I have been attempting to apply patches to both
branches that made sense, but it is possible I missed a few. I will be
taking a second pass at Linux distro bug trackers along with ours.
Is this the big blocker, or are there more that people haven’t raised yet?
