Next release

[angelogladding]

The current v1.1.3 will be the final version that supports python2.

As @sknebel points out #182 (comment) we have introduced a breaking change.

Is there any good reason to reverse that (tiny) change and publish a minor release v1.2?

Either way we're on track for a v2.0 major release. Should we kick the tires of our public API while we're at it?

[sknebel]

@capjamesg merged it after the release, so the release should be ok. The next release should be a major one.

I would not spend much time waiting on other changes, having multiple major releases after another doesnt hurt too much for what we do.

[angelogladding]

What belongs behind a flag? Currently proposed:

• expose_dom=True
• block_roots={...}

>>> parse(url="example.com", expose_dom=True, block_roots={...})

We decided srcset on by default would be an acceptable breaking change on a major version upgrade. lang isn't a breaking change as it never changes the structure of the returned mf2json so no flag for it either?

Should rewriting URLs in e-content require a flag?

[sknebel]

My ideas around this:

1. with no flags set, the parser should produce output as demanded by the spec.
2. Spec changes that break compatibility for consumers (primarily: turning things that never could be an object before into an object) should be major version jumps for the parser IMHO.
3. following from that, any non-standardized or breaking-but-not-major-released behavior should be behind a flag. This includes pure additions made by mf2py (expose_dom, block_roots), experimental code before we are sure a spec change is going to be accepted as implemented and releases of a previous major version that include new behavior (likely primarily cases where experimental code has been standardized in the mean time)

Should rewriting URLs in e-content require a flag?

I guess its just strongly proposed, so one could argue both ways about point 3 above. On one hand, its not yet in the spec, on the other hand I suspect its coming and it seems relatively safe. I'd be fine with either, IMHO primarily we should see to get the spec issue resolved.

[snarfed]

I'm excited about all the changes going into this upcoming release! Can't wait to use it. @sknebel++ agreed, release early and often. @capjamesg @angelogladding thanks for all of your renewed interest and work on mf2py!

[capjamesg]

I think we are ready to do a release after all active PRs are merged. Special thanks to @angelogladding and @sknebel for reviewing and weighing in on several of the active PRs we had, and for contributing code.

@angelogladding Do you want to handle the distribution to PyPi?

Rough steps:

1. Guide open PRs to approval / resolution.
2. Announce in #microformats that we are preparing for a release. Provide a date after which no more contributions will be accepted. Provide a release date.
3. Package the project.
4. Distribute via PyPi.
5. Announce the new version.

[angelogladding]

Let's leave #211 out of the release. I'm not happy with it as is.

And I'd like to give the README a little more attention/cleanup as well.

[sknebel]

👍 it can be added in a minor release without issues

[snarfed]

Could we decide on #213 (comment) before the release? I'm ok with any decision. @capjamesg what do you think?

[sknebel]

213 behind a flag could easily be added in a minor release later if we decide to go with it, no need IMHO to hold up the major jump now.

[angelogladding]

@capjamesg I think we're good to go for a release. Please add the date to the changelog and regenerate the documentation. Can you add a section in the Makefile for "make docs" while you're at it?

[capjamesg]

I left a comment on #213, as I think there may still be a bit more discussion to have before we go ahead with a release. Let's hold off for a day or two to allow more discussion. @angelogladding, documenting your perspective in #213 would be appreciated.

[angelogladding]

I've changed my mind on #211. It's actually doing what it's supposed to do right now. I'm hesitating on the hypothetical conflicting property name. If and when a notable discovery is made we can add property-based blocking.

[capjamesg]

@angelogladding Does that mean you want to include #211 in the release?

[angelogladding]

2.0.1 has been released.

[capjamesg]

Amazing! I'm excited to deploy this on my projects.