1.2.0.beta changelog

[peterqliu]

No description provided.

[asheemmamoowala]

This is a good start, but I think a lot of items have snuck in from the v1.1.1 release, but also a couple from older ones.

Could also use more developer-friendly entries than just the titles from the corresponding PRs/commits

[asheemmamoowala]

This was previously released with 1.1

[asheemmamoowala]

This was previously released with 1.1

[asheemmamoowala]

Internal refactors don't need a changelog entry

[asheemmamoowala]

nit: bug

[asheemmamoowala]

nit: sumarlidason is a mapbox-contributor

[asheemmamoowala]

Doesn't need Changelog entry - fix was pushed directly to publisher-production.

[asheemmamoowala]

Already in v1.1.1

[asheemmamoowala]

ALso in v1.1.1

[asheemmamoowala]

Could use a better description

[asheemmamoowala]

nit: unneccessary newline

[mourner]

This shouldn't be in changelog (no user-facing changes) and this is addressing an earlier PR in the same release.

[mourner]

This is only relevant for core contributors.

[mourner]

Compass isn't tilted by default so I would clarify that as "Add Map visualizePitch option that ...".

[mourner]

For consistency, let's keep items in the same form (i.e. "Fix rendering of ....")

[mourner]

That's too broad. The PR fixes artifacts on tiles where lines go past allowed extent, and also fixes warning about this not appearing.

[mourner]

normalizeTileURL and makeAPIURL are internal functions that are not exposed publicly, so this needs to be rephrased to reflect what changes on the user side. E.g. "Fix malformed urls when using custom baseAPIURL of a certain form".

[mourner]

Both "SDK support spec section ..." items aren't clear for GL JS users. How they really experience this change is updated version support tables in docs, which I'm not sure we should surface in this changelog.

[chloekraw]

Could we add a few words about what this style-spec property enables? e.g.

Add *-sort-key layout property for circle, fill, line layers to enable sorting features within a single layer

[chloekraw]

I would also prefer that we use the `` around style-spec property names; I'm not sure if this is a convention we've been following in practice. so that this entry would say *-sort-key

[chloekraw]

What does this do? If it's not that important, it should be lower in the changelog; if it is that important, its importance and impact should be clearer in the changelog entry

[peterqliu]

It enables users to add maps with access tokens specific to the map, but I'm struggling to make that more clear beyond switching the words around 🤔as for importance, there aren't many other big feature enhancements in this release overall, hence the prioritization

[chloekraw]

Could we limit non-standard abbreviations ("props") and try to be more precise about style-spec property names? e.g. for this entry:

Clarify requirements and restrictions for text-variable-anchor, text-radial-offset, text-offset and text-anchor properties in documentation

[chloekraw]

This entry doesn't meet GL-JS documentation requirements for starting with a verb. Could be rephrased as:

Allow explicit source options to take precedence over TileJSON

or

Make explicit source options take precedence over TileJSON

[chloekraw]

I don't think this PR name is clear as a changelog entry and would prefer:

Fix bug where previous anchors set in text-variable-anchor were still preferred after anchor options were reset

[peterqliu]

the change emphasizes that previous positions would get prioritized only if they're also present in the updated style value, but i'll figure out a way to articulate that

[chloekraw]

@peterqliu, I did a pass through merged PRs for notable PRs that might be missing from the changelog. I think the only things are the caching fixes @ansis made:

I'd say

Fix unbounded memory growth caused by failure to cancel requests to the cache (#8472)

should definitely be included in the 1.2 changelog;

#8392 also looks significant enough to me for the changelog, since this regression was released in 1.1 and cherrypicked & fixed in 1.1.1. However, I noticed it also wasn't included in the 1.1.1 changelog, so I guess it could be clearer to exclude the fix from both changelogs.

[chloekraw]

LGTM % a few comments to consider

[chloekraw]

Hmmm, was this change made based on feedback from @mourner or @asheemmamoowala? If so, LGTM.

If not: specifying a breaking change like this is confusing to me as a user. I would prefer the following:

• Remove "BREAKING:" from the changelog and leave it in the bug fix section with the parenthetical note as-is, OR
• Flag as a breaking change in its own section like we would usually do (see https://github.com/mapbox/mapbox-gl-js/releases/tag/v1.0.0 for an example) and note that it also fixes a bug

I prefer option 1 -- I don't think that the impact of this change is large or will break customers' maps in unexpected ways.

[chloekraw]

I'm not sure how much this distinction matters, but *-sort-key impacts the draw order of features which is what makes it appear as though it's possible to sort features within a layer. Now that I'm reading this changelog entry with the addition of "z-index," it adds a level of precision that now makes the changelog entry feel less accurate to me, but I would defer to @ahk on this.

I'd probably prefer "...to control the draw order of features..." or the more general "to sort features within a single layer."

[ahk]

How about "Add *-sort-key layout property for circle, fill, and line layers. Allows specifying the order that features are drawn within a layer."

[asheemmamoowala]

nit: subtopics of the version should be H3 aka ### . Could use an edit to v1.1.1 as well

[chloekraw]

oof, great callout @asheemmamoowala but we've done this incorrectly for many releases. e.g. https://github.com/mapbox/mapbox-gl-js/releases?after=v0.50.0-beta.1 and https://github.com/mapbox/mapbox-gl-js/releases?after=v1.0.0

[mourner]

@chloekraw @peterqliu since all the caching fixes were included in v1.1.1, why would we include them in v1.2.0? Changelog should reflect changes since the previous version, not the previous minor version, so duplicating these entries would be confusing.

[chloekraw]

@mourner ahh ok, that makes sense. I'm indifferent as to whether we let this one be or we open a new pr to fix it. It seems small enough that it's probably not a huge deal either way.

I'm accustomed to publishing a retroactive patch release (e.g. 5.1.1) after the latest minor release (5.2) has been published, in which case, a patch's changelog would still contain bug fix entries from the latest minor release.

[mourner]

I'm accustomed to publishing a retroactive patch release (e.g. 5.1.1) after the latest minor release (5.2) has been published, in which case, a patch's changelog would still contain bug fix entries from the latest minor release.

@chloekraw that's a reverse situation — a retroactive v5.1.1 release would show changes vs the previous release relative to it (v5.1.0). v1.2.0 on the other hand is not retroactive — it contains all the fixes v1.1.1 has.

[chloekraw]

yep! I'm agreeing with you; I was sharing that I missed how this convention (to only show changes since the previous release) impacts changelogs when there is a patch because I'm accustomed to the reverse situation.

[chloekraw]

I'm all for fixing this and the heading in a new pr if that's still easy to do at this stage of the release.