Hi Noel - I'd be happy to put together some Docker recipes for the most important platforms and all their versions OpenBabel is supposed to support. If that's done then anyone with docker installed on their machine could just run single commands to confirm that OpenBabel builds and tests pass on each platform with the appropriate dependencies. Does that sound like something you'd be interested in?
As an example, I have a recipe here for RDKit+GPUSim on Ubuntu with Cuda drivers: https://github.com/schrodinger/gpusimilarity/blob/master/docker/Dockerfile That pulls down RDKit and builds it on Ubuntu - in this case to be used with GPUSim, but you can see it'd be trivial to just run the tests at the end. This is how I guarantee my changes on GPUSim are working on Ubuntu (the most popular platform for it) even when I do all my dev on Arch. Pat On Fri, Sep 6, 2019 at 9:27 AM Noel O'Boyle <baoille...@gmail.com> wrote: > Hi all, > > Geoff asked me to bring up the discussion of a release schedule for OB > 3.0. It's been so long since the last release, that it's become painful for > us to do a release, which is a bit of a vicious cycle as you can imagine. > So.... > > I have some time to do this now (with help I hope!) so I'm going to > randomly suggest that every Friday until finished, we do a release. Every > Monday morning, I'll bump the version and tag that git revision, and > between then and end of Friday we'll try and get all parts of the release > done. > > So next Friday we do a release - it might be 3.0a, and the release notes > out of date, Python 2 unsupported and conda only working on Linux. And the > following Friday - it might be 3.0a2, but most parts of the release have > been automated and updated. And so on, until we have 3.0 - the goal is the > last Friday of September. > > The reason we need to do this is that we need to start oiling our release > procedures, and get things automated (as much as possible). Get release > scripts together - check them in somewhere - and make it so that creating a > release is not painful. Frequent releases are a great spur to doing this > even if only alpha releases. > > With this in mind, I'm going to suggest that we feature freeze and focus > on release blockers. We shouldn't be dogmatic (e.g. I note that I have > already agreed to review/merge David Koes mega PR) but we should try to > avoid making the documentation out-of-date during the release procedure. If > everything gets super automated, it will not be difficult to do another > point release in 3 or 6 months so no-one should panic that their work will > have to wait for another 3 years. > > So if people want to help we will need testers for the conda packages, the > snap packages, the Python binaries, etc., etc. Does it build on Ubuntu? > Does it build on Arch? Help updating the documentation would be much > appreciated - you can do this directly on the github repo. If you want to > help but don't know how/where, just email the list - there are many things > that we would do if we had more time, so don't hold back. > > Geoff - does this sound reasonable? I can send to openbabel-discuss also > if it's okay. > > Regards, > Noel > _______________________________________________ > OpenBabel-Devel mailing list > OpenBabel-Devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/openbabel-devel >
_______________________________________________ OpenBabel-Devel mailing list OpenBabel-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openbabel-devel
