Ozone ready for version 2?

[Milind220]

Version 2.0.0 is almost here!

we've fixed some bugs, and added some breaking changes - and Ozone is much more robust now!
We also added tests - and Ozone finally passes them all :)

Also, thank you all for your contributions to Ozone! It's all of you that make this possible :)

Special shoutout to @lahdjirayhan and @Sam-damn
💯🔥
@AliShahpurwala @Tomiiwa @ShootGan @corey-new @ubongab @iGotAdigBick @kowshik-noor @Amitesh100 @kristinamancini @tariksouabny

Does anyone have anything urgent that they'd like to add in time for Ozone v2.0.0?

[lahdjirayhan]

#151, but I don't want to unilaterally decide and open PR just yet.

[lahdjirayhan]

Uh oh, didn't realize we've gone to 2.0.1 by now. I was away on holiday.

[Milind220]

@lahdjirayhan Ahh I just looked at everything and couldn't see anything else that might constitute a breaking change. Everything else I could see felt more like a patch.

[lahdjirayhan]

@Milind220 I see my proposed options as breaking change because:

• Option 1 removes functionality, and thus is a breaking change.
• Option 2 removes the file_name argument from __init__ and adds file_name argument in public methods. Would break code that supply file_name argument when instantiating.
• Option 3 same as 2.

I'm not sure how can we work around it without breaking changes? So long as file_name is supplied in __init__ and become an attribute, users that call public methods (e.g. get_city_air) repeatedly will see their output files get overwritten albeit with a custom filename.

[lahdjirayhan]

Oh yeah I'm sorry I wasn't explicit enough with my wording in that issue thread esp this one

• Option 2 removes the file_name argument from __init__ and adds file_name argument in public methods. Would break code that supply file_name argument when instantiating.

[Milind220]

@lahdjirayhan Hey, I'm so sorry I've been really busy for a couple days (started an internship).

Also, I'd like to apologise for rushing ahead to version 2. Should've waited for some more input before releasing that.

Out of the three options, I actually think that perhaps removing the functionality to save directly to a file is best. It would result in the cleanest API for ozone. Also, as you said, to save data frames to files is super straightforward, so instead of us calling the methods under the hood our users can just call them directly.

Since this would indeed constitute a breaking change (😢 Next time I'll wait) we're going to have to release version 3.0 to incorporate this.