Release Schedule

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.

For you entertainment I created some subversion stats:
http://avogadro.sourceforge.net/stats/

Enjoy.


Donald Ephraim Curtis

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.)

For you entertainment I created some subversion stats:
http://avogadro.sourceforge.net/stats/

There’s also Ohloh, although it runs maybe a week or so behind:
http://www.ohloh.net/projects/4241

Cheers,
-Geoff

P.S. It’s funny to see Open Babel’s Ohloh listing. You can see when I
cut out the auto-generated SWIG code:
http://www.ohloh.net/projects/392/analyses/latest

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.

Cheers,
-Geoff

On Thursday 03 May 2007 21:43:41 Geoffrey Hutchison wrote:

I’ll see if I can figure out the smallest subset of Qt libraries.

I guess that would be:
QtCore
QtGui
QtOpenGL

Cheers,
Benoit

On May 3, 2007, at 3:46 PM, Benoît Jacob wrote:

I’ll see if I can figure out the smallest subset of Qt libraries.

I guess that would be:
QtCore
QtGui
QtOpenGL

My guess too. But since I have all of them installed, I’ll need to
find a “clean” computer to test the installation. That’s basically
what I meant.

Cheers,
-Geoff

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.


Donald

(Thu, May 03, 2007 at 09:47:52AM -0400) Geoffrey Hutchison geoff.hutchison@gmail.com:

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.)

For you entertainment I created some subversion stats:
http://avogadro.sourceforge.net/stats/

There’s also Ohloh, although it runs maybe a week or so behind:
http://www.ohloh.net/projects/4241

Cheers,
-Geoff

P.S. It’s funny to see Open Babel’s Ohloh listing. You can see when I cut
out the auto-generated SWIG code:
http://www.ohloh.net/projects/392/analyses/latest

Just a little more information:

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.


Donald

(Thu, May 03, 2007 at 09:47:52AM -0400) Geoffrey Hutchison geoff.hutchison@gmail.com:

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.)

For you entertainment I created some subversion stats:
http://avogadro.sourceforge.net/stats/

There’s also Ohloh, although it runs maybe a week or so behind:
http://www.ohloh.net/projects/4241

Cheers,
-Geoff

P.S. It’s funny to see Open Babel’s Ohloh listing. You can see when I cut
out the auto-generated SWIG code:
http://www.ohloh.net/projects/392/analyses/latest


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/


Avogadro-devel mailing list
Avogadro-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/avogadro-devel

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?


Donald

2007/5/15, Donald Ephraim Curtis d@milkbox.net:

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…

Carsten

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.

Just my $0.02,
-Geoff

On Tuesday 15 May 2007 18:42:43 Carsten Niehaus wrote:

2007/5/15, Donald Ephraim Curtis d@milkbox.net:

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.

I think we need to set a release schedule ASAP.

  1. 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.”

  2. 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. :wink:

Cheers,
-Geoff

On Thu, Jan 20, 2011 at 4:40 PM, Geoffrey Hutchison geoff.hutchison@gmail.com wrote:

I think we need to set a release schedule ASAP.

  1. 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.

  1. 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. :wink:

Yes, I see rumblings from distros. I would like to push out a 1.0.2 ASAP too.

Marcus

21.01.2011, 00:40, “Geoffrey Hutchison” geoff.hutchison@gmail.com:

I think we need to set a release schedule ASAP.

  1. 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

  1. 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


Regards,
Konstantin

On Jan 21, 2011, at 3:46 AM, Konstantin Tokarev wrote:

Surely. However, one unresolved crash case with H bonds remains unfixed

Can you point me at that one?

Thanks,
-Geoff

21.01.2011, 18:49, “Geoffrey Hutchison” geoff.hutchison@gmail.com:

On Jan 21, 2011, at 3:46 AM, Konstantin Tokarev wrote:

Surely. However, one unresolved crash case with H bonds remains unfixed

Can you point me at that one?

http://sourceforge.net/tracker/?func=detail&aid=3091185&group_id=165310&atid=835077


Regards,
Konstantin

21.01.2011, 19:02, “Konstantin Tokarev” annulen@yandex.ru:

21.01.2011, 18:49, “Geoffrey Hutchison” geoff.hutchison@gmail.com;:

On Jan 21, 2011, at 3:46 AM, Konstantin Tokarev wrote:

Surely. However, one unresolved crash case with H bonds remains unfixed
Can you point me at that one?

http://sourceforge.net/tracker/?func=detail&aid=3091185&group_id=165310&atid=835077

This patch fixes some crashes:


Regards,
Konstantin

On Jan 21, 2011, at 11:18 AM, Konstantin Tokarev wrote:

https://github.com/cryos/avogadro/commit/f54ae503333f9b3574d227d4ff42a3ca2ad4c5e2

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.

Thanks,
-Geoff

On Sat, Jan 22, 2011 at 9:43 PM, Geoffrey Hutchison geoff.hutchison@gmail.com wrote:

On Jan 21, 2011, at 11:18 AM, Konstantin Tokarev wrote:

https://github.com/cryos/avogadro/commit/f54ae503333f9b3574d227d4ff42a3ca2ad4c5e2

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?

Marcus

23.01.2011, 05:43, “Geoffrey Hutchison” geoff.hutchison@gmail.com:

On Jan 21, 2011, at 11:18 AM, Konstantin Tokarev wrote:

https://github.com/cryos/avogadro/commit/f54ae503333f9b3574d227d4ff42a3ca2ad4c5e2

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.

Correct. I’ve put it here just to remind you what it was about


Regards,
Konstantin