3.0 Feature Freeze

[fonnesbeck]

Since the release of the last RC, there has been a fair amount of feature contributions (which are much appreciated, by the way). I'm worried about adding a raft of new code between a RC and the release. I propose that we hold off on merging additional functionality until we release.

The main obstacle to a release at this point is getting HMC/NUTS to initialize and run reliably. Once that is done, I'm happy to get it put the door and allow folks to contribute new functionality to 3.1.

Thoughts?

[ColCarroll]

Good idea -- making sure everything works well and is trustworthy is important for a release.

Probably safest is to start a 3.1 branch -- development of new features could keep happening there, but only bugfixes or necessary enhancements go into master?

[springcoil]

That's a good idea @ColCarroll

[twiecki]

OK, so we merge #1523 to fix initialization, then release. In the mean time merge to 3.1 branch.

[ColCarroll]

Just made the branch and merged #1530 into it. That's one thing to keep an eye on while finishing up the release: PRs will still be against master by default.

[fonnesbeck]

So, this will be merged back into master when 3.0 is released, correct?

[twiecki]

That's my assumption.

[ColCarroll]

Yeah -- so if developing new features, you should develop on branch 3.1, and whenever something is merged into master, the 3.1 branch will need to be rebased.

There are benefits to maintaining this sort of structure: in particular, if master is always the latest pypi release, and there's a develop or semvar (3.1, 3.2, ...) branch where new features go. It comes with some cognitive overhead, though, and it seems like it isn't necessary here.

[twiecki]

@ColCarroll I've worked with that framework before but decided I don't like it, too much cognitive overhead. So after the feature freeze I propose to go back to a single master branch.

[fonnesbeck]

Sounds good. My only worry is that merging back will be a bear if there is a lot of new feature development. Perhaps a weekly rebase to keep them aligned?

[twiecki]

@fonnesbeck Valid concern. We should move ahead with 3.0 soon in that case. I think most issues are resolved at this point?

[ColCarroll]

@twiecki 👍 just wanted to make sure it was mentioned as a possibility, and agree with the rebase concerns. Really, there can be a rebase after any PR is merged to master -- there will still be problems if 3.1 gets too far ahead, but they'll be smaller.

[springcoil]

👍

On Fri, Nov 18, 2016 at 2:30 PM, Colin notifications@github.com wrote:

@twiecki https://github.com/twiecki 👍 just wanted to make sure it was
mentioned as a possibility, and agree with the rebase concerns. Really,
there can be a rebase after any PR is merged to master -- there will still
be problems if 3.1 gets too far ahead, but they'll be smaller.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#1526 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AA8DiN7LjQVE_F3tq8o_tJTQlW90-Prsks5q_bZogaJpZM4Kwjnq
.

Peadar Coyle
Skype: springcoilarch
www.twitter.com/springcoil
peadarcoyle.wordpress.com

[fonnesbeck]

@twiecki my own feeling is once we get the bad init/stalling problem(s) out of the way, 3.0 should be released.

[twiecki]

@fonnesbeck So should check those examples if the new ADVI fixes them.

[twiecki]

@fonnesbeck I went through some older issues which are now fixed. I think you also reported a few models where you had issues so after you confirm on those we should be good to go!