Hey everyone, Another follow-up from the meeting.
On Fri, Apr 05, 2019 at 02:48:28AM +0200, Marcus Edel wrote: > The next release of mlpack will be 3.1, it has taken far to long and part of > the > problem was the tedious deployment process. There are a couple of open PR's > that > will probably go into mlpack 3.1 that are close to finish. Interesting note, > almost all PR's are adding new features, so we don't have to wait/prioritize > PR's that will fix bugs. > > * All PR's mentioned in the slides that are already merged will go into the > new > release, that includes all the work from last years GSoC. > * If anybody can think of something that shouldn't go into the release please > let us know. > * Some of the smaller PR's will be part of a patch release after mlpack 3.1. There were a few PRs that I had questions about but they actually got merged before I could write this email. The only remaining PRs on my "need to merge before 3.1.0" list are the new PRs #1855 and #1856 before we release 3.1.0, since those are bugfixes. After talking to Shikhar, I'll remove the GAN support from 3.1.0 since it is not quite ready yet. I'm sending this email to ask if there are any PRs we should really consider merging before 3.1.0 (i.e. critical bugfixes or important functionality additions). Note that we can release 3.1.1 shortly afterwards as we add more PRs, so I'd prefer to have a good justification to hold up the 3.1.0 release for a PR. If you have or know of a PR that you think is sufficiently important, please speak up. :) Similarly, if you know of support that should not be a part of the release, please speak up. :) In the absence of any additional PRs to be merged or discussed, I will try and release 3.1.0 as soon as I have a chance. Let me say optimistically that I think I can have it done by the end of this upcoming weekend, but pessimistically I will say that I'll probably get sidetracked until some time next week... The automated release process should significantly ease the overhead of a release, and I will refine this as we go forward. I hope to have releases almost as regular as ensmallen, where the release frequency is "basically every time we merge a PR" since I literally just run a script and everything is updated. Of course that won't be entirely applicable to mlpack since it is a much more complex piece of software, but we can do better than I've managed to do for us in the past for sure. Thanks! And please accept my apologies because I have been saying this would happen since last August or even earlier... Ryan -- Ryan Curtin | "I'm just going to shoot you once!" [email protected] | - Joseph Dunn _______________________________________________ mlpack mailing list [email protected] http://knife.lugatgt.org/cgi-bin/mailman/listinfo/mlpack
