Toward a new stable release... (2.3.0) and other news

[Julien Yann Dutheil]

Dear all,

Here come a few news:

- Bio++ libs and progs will be back (up-to-date) in debian (and ubuntu etc). The Debian Med Team took over the maintenance of the packages, which is excellent news (1,000 thanks to them!). We're currently working on having 2.2.0 in debian (last version was 2.1.0). 

Consequence 1: I will no longer maintain the local ubuntu repository at biopp.univ-montp2.fr, which would be redundant.

Consequence 2: for ease of integration with the Med team, we will go back to the tag system for marking releases on the git repository (currently we create a separate branch for each stable distribution). This does not prevent anybody however to branch the libraries at any stable release point.

- We should really start to think of a new stable release. Apart from the usual fixes and updates, I have here a few points on the list:

* upgrading to C++0x (most likely c++14). I had created a separate branch some time ago, I am planning to merge it. One additional reason to do so: c++14 (actually gnu14, which includes the gnu extensions) will be the default std mode in g++-6! So time to move forward...

* including the new "Graph" classes developed by Thomas (they are already there as a matter of fact).

* including the 'probseq' branch developed by Murray (sorry, I'm so delayed with that :s)

* including newlik? If I'm correct, the classes cannot yet superseed the old ones. But as they are more and more used, shouldn't they be side by side with the old ones on the master branch? (java used to have two types of GUI classes for instance, the "old" ones and the "new" swing classes). That would maybe push the development of newlik, what do you think? Is that possible / desirable?

* anything else?

Cheers,

Julien.

[Laurent Guéguen]

Hi Julien,

yes indeed it would be nice to have a new stable version; I hope it will to too hard to do it.

Concerning newlik, helas these classes do not cover yet all former likelihood classes could do, but they can do
many much other things. And since they get more and more used, I think it a good idea to put them in master.

However, it will be more tricky with bppsuite, since the BPPO declaration syntax is completely different. 

Cheers,
Laurent

[Julien Yann Dutheil]

Hi Laurent,

what exactly is still missing? is that only substitution mapping and ancestral state reconstruction?

If so I think we could have bppml switch to newlik in bpp suite, while other progs such as bppancestor could still use the current ones.

The BppO syntax thing is more annoying... what is changing? I guess it is the way you describe the model as a whole (while substitution models per se do not change) ? That is of course more tricky as the output of bppml would be incompatible with bppancestor and bppseqgen... maybe we should have two bppml then,one unsing newlik and one for compatibility?

J.

[Laurent Guéguen]

Hi Julien,

ancestral site reconstruction is done, but not substitution mapping.
bppseqgen is done too.

non-homogeneous mixture models are missing (I was waiting for the new tree classes,
but I am afraid I will have to do without them).

Management of topology changes is missing too, I hope I implemented well enough to
make it easy.

Much things have changed in the syntax, but it will be easy to wrap the old one in it.
The model are declared the same, but now we declare the process (ie link model, tree),


Cheers
L

and the phylolikelihood (ie linjk process, data).


 

[Laurent Guéguen]

Hi again,

what I will do now is to change the input of all bppsuite programs such that they follow the new BPPO syntax.
And the  testnh ones too I think?

A+
L

[Julien Yann Dutheil]

Portage to C++14 committed on master branch... Please report any trouble!

Now compiling with g++6 for a check...

J.