On Wed, Oct 2, 2013 at 2:40 AM, Maciek Wójcikowski <mac...@wojcikowski.pl>wrote:
> I'd like to bring the topic of release frequency of OpenBabel to the
> table. Since OB was migrated to the GitHub its development has speed up
> noticeably. Last release 2.3.2 was almost one year ago, and I think it's
> good time to discuss that matter. One major problem I've noticed is that
> many commits are rather bugfixes and minor enhancements, rather than
> changing ABI/API. And those bugfixes are rather usefull to have, so the
> real solution is to use development version.
>
> I believable that the best route we could take here is similar to RDkit is
> having. I'd like to propose to enumerate the API/ABI versions and introduce
> quarterly code freezes with all the bugfixes and major enhancements, f.e.
> the next release could be named 2.4_2014Q1 and so on.
>
> What do you think about such release strategy?
>
I think it's nice in theory, but won't work in practice. Unlike large
projects such as Linux or Postgres, the OpenBabel "team" has very few
regular contributors. We (that is, mostly Geoff, with help from Noel, Chris
and a few others) do work when we can. Releases are done not because of a
schedule, but rather because there's a reason, such as critical bug fixes
or important new features. Nobody is getting paid; we do it when we can.
On the other hand, there is no reason why you shouldn't use the developer
versions if you need bugs and/or features that have been committed since
the last release. I don't think eMolecules.com, which is probably the
biggest user of OpenBabel in terms of CPU-hours, has used an official
release of OpenBabel since we went online in 2005.
The idea of "releases" is getting vague since there is an automatic nightly
build/test system. Geoff can correct me if I'm wrong, but I don't think
there is a huge amount of additional testing that goes into an official
release. An official "release" mostly ensures that someone didn't check in
some code in the last couple nights that broke something.
Regarding version numbers: I'm very much against changing the 1.2.3 format
into something that includes the date. One of the cardinal rules of
database design (which sort of applies to version numbers) is, "Don't put
meaning into primary keys." That is, identifiers should contain as little
information as possible. I can tell at a glance that 1.2.3 is prior to
1.2.4, and that 1.3.1 has a different API than 1.2.2. I can easily remember
that I'm using 1.2.3. But if I see 1.2_2013Q2 verus 1.2_2012Q3, which one
is newer? It takes a second to figure it out. And who cares what the date
was? The relevant questions are: A) Is this version's API is compatible
with my code, and B) Which version is newer? Adding a date doesn't even
tell you whether it's the very latest or not; you still have to go to the
OpenBabel web site to see.
So my vote is against changing the release numbering scheme.
Craig
>
> ----
> Pozdrawiam, | Best regards,
> Maciek Wójcikowski
> mac...@wojcikowski.pl<https://mail.google.com/mail/u/0/?view=cm&fs=1&tf=1&to=mac...@wojcikowski.pl>
>
>
> ------------------------------------------------------------------------------
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
> from
> the latest Intel processors and coprocessors. See abstracts and register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk
> _______________________________________________
> OpenBabel-Devel mailing list
> OpenBabel-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openbabel-devel
>
>
------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk
_______________________________________________
OpenBabel-Devel mailing list
OpenBabel-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openbabel-devel
