Plasmapy: Planning our version 0.1 release

[namurphy]

We are presently in the early stages of development, and it is probably worth thinking about what we want to include in our first micro version of PlasmaPy. My hope is that we will have something that is useful enough that it would be worthwhile for plasma physicists to install, though not so ambitious that it would take us more than ~3-6 months to complete. I'll create a few milestones with GitHub so that we can start to keep track of things like this.

A very incomplete list of the things that I've been thinking about include:

• Ability to calculate most needed plasma parameters, transport coefficients, and dimensionless numbers (https://github.com/PlasmaPy/PlasmaPy/pull/34)
• A prototype Plasma class (see https://github.com/PlasmaPy/PlasmaPy/issues/23)
• Good documentation for the features that are included (https://github.com/PlasmaPy/PlasmaPy/issues/30, https://github.com/PlasmaPy/PlasmaPy/issues/31)
• Making sure that the code of conduct and vision statement are consistent with each other (https://github.com/PlasmaPy/PlasmaPy/issues/15)
• 10,000 space wombats

I'm not sure if we want to include rudimentary simulation capabilities yet, since those could end up being quite ambitious and might be worth including in a 0.1 release instead. What are other things that we should include in 0.0.1?

[SolarDrew]

Space wombats...?

I'd say my approach at the simulation aspect can be 'working' in that timeframe, but not necessarily properly tested and verified. I think we should set a date for this as well, I think setting deadlines will help us push on with things and make sure we get regular releases out.

[Cadair]

Following semantic versioning your first release should be numbered 0.1 http://semver.org/#how-should-i-deal-with-revisions-in-the-0yz-initial-development-phase 0.1.1 would then be your first bug fix release and 1.0.0 would be for your first "major" release.

0.0.1 would be the first bug fix release for the 0.0 series, which means your first release should be 0.0.0 not 0.0.1 which is a little weird, hence the 0.1 not 0.0 ;)

[SolarDrew]

But zero-based indexing.... :P

[Cadair]

I mean release version 0.0.0 if you want :D

[namurphy]

That is helpful, @Cadair! Following your suggestion, I will rename this issue so that we're discussing what to include in 0.1. Would December/January be a good time to tentatively plan for a 0.1 release?

[SolarDrew]

December/January sounds reasonable to me, depending on how much ends up going in it.

[namurphy]

I tentatively put January 18, 2018 as the v0.1 due date, though this is arbitrary so I am completely open to changing it (especially if there are meetings or other conflicts that core developers have). I'll probably regret it on January 17! :crying_cat_face: We would probably want a feature freeze, beta release, and branch created a month before, and a release candidate a week before if we follow Astropy's stated practices.

Useful links:

• Astropy release schedule and version numbering - I'm happy to learn from Astropy and SunPy whenever possible!
• Emoji cheat sheet for GitHub and other sites

[SolarDrew]

Sorry! Wrong button! 18th of January sounds good to me. And I think that list of features is a good starting point, perhaps with one or two more major-ish features added.

[lemmatum]

Seeing as we're about a month away from tentative v0.1 milestone, it might be a good time to review what progress has been made, what needs to be done, and prioritize open issues.

[StanczakDominik]

181 tries to handle this a bit. I'll keep this open for discussion, though.

[StanczakDominik]

Seeing as we're about a month away from tentative v0.1 milestone, it might be a good time to review what progress has been made, what needs to be done, and prioritize open issues.

Welp.