[mlpack] mlpack 3.1.0 release plan (was: mlpack video meeting)

[Ryan Curtin]

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!"
ryan at ratml.org |   - Joseph Dunn