Future Release Schedule

Development
1

There’s a list of major things that users probably want before a 2.0 release:

  • basic UFF implementation
  • optimization constraints (these actually go together since they both require the same gradients)
  • auto-optimize tool

(I’m sure there will be a pile more feature updates, but IMHO that’s the last major feature I can think of.)

But the main thing people seem to want are more frequent (non bug-fix) releases.

I have some thoughts… First off, it seems like a good idea to have a January / Februrary release (e.g., 1.99) for Linux LTS packaging.

So a rough deadline might be 06-Feb (or 06.02 in dd/mm dates :wink:)

Then a fall deadline might be “mole day” in the US or 10/23

If we wanted to add a third release, a deadline might be e.g., 06/02 (June 2nd) with US dates.

  • 06-Feb
  • June 2
  • Oct 23

The dates are fairly well spaced, and happen to be Avogadro related. :wink:

The other side would be to add a feature freeze and “string freeze” date to ensure translators have time to update. I’d suggest at least 2 weeks before the release date, which gives time to also fix remaining bugs, tweak docs, etc.

Thoughts?

2

I think this all looks pretty good. I’m curious about the UFF implementation you mentioned, what all needs to happen for that?

3

I’m all for more frequent releases, they take the pressure off each individual release.

Your specific schedule sounds good too, as you say, well spaced. A formal feature freeze seems sensible.

So I guess your target would be October for the 2.0 release and have a 1.101 in June?

4

I’d like to get 1.100 out soon. As far as future numbers? Guess it depends on how hard it is to finish and test the remaining bits. :smiley:

(In other words if 2.0 is in good shape for June, all the better)

1 Like
5

Oh, right, I left off a few builder bits:

  • peptide builder
  • polymer builder

(These are actually fairly similar because they build up the geometry from a z-matrix)