Yes, I think we’ll still be able to do bugfix releases for the 3.5.x series, but it will certainly be easier to backport before we merge with 4.0, particularly for anything in the SPH or particle frontends or infrastructure.

On Mon, Oct 15, 2018 at 11:06 AM Cameron Hummels <chummels@gmail.com> wrote:
That sounds good.  I guess that gives us a little time to potentially put out a 3.5.1 if there are any bugs we missed in the 3.5 release. 

Cameron

On Mon, Oct 15, 2018 at 9:02 AM Nathan Goldbaum <nathan12343@gmail.com> wrote:
Hi all,

I'm cutting the 3.5 release and realized we didn't have a discussion about what the version number on master should be after we release 3.5.

Our next planned release is 4.0, we're not currently planning on doing a 3.6 release. That said, i think the version number on master should be 3.6.dev0. This doesn't indicate that we're going to release 3.6, it just makes it easier to track since the version number on the yt-4.0 branch is already 4.0.dev0. I don't think it makes sense to have two branches where that's the version number.

Does anyone have any objections to setting it up like that? Hopefully we'll be able to merge the yt-4.0 branch into master before too long and not have to deal with the distinction. There are still a few tech debt things I want to clear up before merging, but we're in a much better position than we were before Ash's GSOC project at the beginning of the summer.

-Nathan
_______________________________________________
yt-dev mailing list -- yt-dev@python.org
To unsubscribe send an email to yt-dev-leave@python.org


--
Cameron Hummels
NSF Postdoctoral Fellow
Department of Astronomy
California Institute of Technology
_______________________________________________
yt-dev mailing list -- yt-dev@python.org
To unsubscribe send an email to yt-dev-leave@python.org