Proposal: API change freeze

[ILOVEPIE]

We should try and get in all API breaking changes and then put in a freeze on API breaking changes so that we can get 2.0.0 released sooner rather than later. There's a lot of people who are waiting on some of the changes we have in it. We can still accept features that don't break API. This means that we can bugfix and get ready for a release. It also means that I'll have the chance to update the closure compiler externals.

[herrstrietzel]

As a user I totally agree.

Imho a sooner release of v2.0.0 makes sense - even if the new release contains minor issues. In fact a "jump into cold water" is necessary since a lot of people are still using an outdated version (me included) and the gap between the new functions becomes bigger and bigger.
I think issues when upgrading can significantly be mitigated by addressing the major changes in the readme and for instance providing versioned CDN links and notices which functions are only available since version 2.0.0. E.g something like this

The Font.variation object (VariationManager) (new in version 2.0.0)

[ILOVEPIE]

As a user I totally agree.

Imho a sooner release of v2.0.0 makes sense - even if the new release contains minor issues. In fact a "jump into cold water" is necessary since a lot of people are still using an outdated version (me included) and the gap between the new functions becomes bigger and bigger.
I think issues when upgrading can significantly be mitigated by addressing the major changes in the readme and for instance providing versioned CDN links and notices which functions are only available since version 2.0.0. E.g something like this

The Font.variation object (VariationManager) (new in version 2.0.0)

I'd rather honestly include the readme in the release itself so that that can be the main reference. So basically what would happen is the readme on the repository would be only for people who are using the main repository whereas the one in the package itself would be used for that version.

[Connum]

Good idea with the feature freeze, but we should get all the PRs in that we marked for 2.x.x and get the number of open PRs down before, in case they necessitate API changes.

[ILOVEPIE]

Good idea with the feature freeze, but we should get all the PRs in that we marked for 2.x.x and get the number of open PRs down before, in case they necessitate API changes.

I hope you mean the 2.0.0 milestone because the 2.x.x milestone is for subsequent releases after 2.0.0 that aren't API breaking.

[Connum]

Yes, of course. I didn't remember we had that one already

[ILOVEPIE]

I think we should go and look through all of the PRs that are in the 2.0.0 release and move ones that are not API breaking that seem to be stalled to the 2.x.x release.

[Connum]

Excellent idea!