Release 1.9

[jonkoops]

No description provided.

[jonkoops]

@mourner @IvanSanchez @Falke-Design I think it's time we start prepping the 1.9 release, let's use this issue to coordinate our efforts on what we still need to do before release. I'm updating the 1.9 milestone so we have all of the work in there that was merged since the last release.

[jonkoops]

Okay, I've added all of the changes to the correct milestone. Perhaps one of you could run through it to see if I missed anything?

[Malvoz]

Aside from the issues and PRs in the 1.9.0 milestone, there are other PRs that already have been approved, maybe they can be merged in too before releasing?

[Malvoz]

Okay, I've added all of the changes to the correct milestone. Perhaps one of you could run through it to see if I missed anything?

I appreciate the push towards a release, but was that step needed? I just removed #7851 from the 1.9.0 milestone, since it was released with 1.8.0 (not to be confused with #8211). We should instead create a changelog from the list of commits since the v1.8.0 release.

[jonkoops]

Just some bookkeeping as I want to use the milestone to compile the changelog. I've used the list of commits to assign them to the correct milestone, but we can also just use the commit log as a reference.

I think we should go ahead with the release of 1.9 without merging in more work. Perhaps we can start releasing some betas?

I'd like to write a statement for the 2.0 release about our support for ES modules. I'd also like to mark the UMD module format and global API as deprecated with the intention to remove them together with Internet Explorer support in version 2.0. Naturally the globals are to widespread, so an import will be provided to restore behavior.

[Falke-Design]

I created the Changelog for 1.9.0. I created a gist because I hope that not everyone gets a mention notification.

@jonkoops @Malvoz @IvanSanchez @mourner can you please look over it: https://gist.github.com/Falke-Design/9da6ba06be7d2cf357312a805b9e3205

We have currently one blocker open: blocker Critical issue or PR that must be resolved before the next release

[mourner]

@Falke-Design this is great! I merged your blocker fix. Let me do an edit pass on the changelog and I'll do a release on Monday (it's usually considered a bad practice to release on Friday night or weekend). Thanks everyone for you help.

[Falke-Design]

@mourner Perfect! I will look that I create the 2.0.0 Changelog until monday too. @jonkoops do you want to create a 2.0.0 branch and merge the PRs of the 2.0.0 milestone?

Did you consider releasing a beta?

[jonkoops]

@Falke-Design Thank you so much for creating the release notes, that's a huge help! Yeah, might be a good idea to release a beta first. I want to ensure the enablement of ES modules in #8329 does not cause any unexpected issues in edge cases.

As for 2.0 that is a good question, perhaps we want to create a dev branch where all the latest development takes place? If we need to backport anything to 1.x then we can cherry pick these commits on main and run a release.

@mourner What do you feel would be the best approach here?

[mourner]

Let's not rush too much on v2 and discuss the approach after we release v1.9.0 (apologies for the delay, got sick).

I'd say that once we decide to focus on v2 going forward, I'd do the other way around — development in the main branch, while keeping a long-living v1 branch for important v1 bugfixes (hopefully infrequent).

[jonkoops]

development in the main branch, while keeping a long-living v1 branch for important v1 bugfixes (hopefully infrequent).

Yeah, that sounds like a better plan. We can always backport critical features.

[jonkoops]

@Falke-Design I've pasted the releases notes into a draft release which is only accessible to us. You can find it on the under the Releases section.

[Falke-Design]

@jonkoops the Release notes looking good for me. We should not forget to add them in CHANGELOG.md too

[jonkoops]

Yeah, that will be part of the release process. @mourner if it's alright with you I'd like to give it a whirl to run a beta release early next week. It's probably good for me to familiarize myself with the release process.

[mourner]

I made a quick edit pass on the changelog in the release draft — looks great @Falke-Design!

@jonkoops sure, go for it! I'm wondering whether there should even be a beta, since it's a release without notable breaking changes unlike v1.8.0. Maybe worth just releasing v1.9.0 final outright? And doing v1.9.1 shortly if we discover any issues. This makes the overall release process a little simpler and less intimidating.

[Falke-Design]

@mourner there should be no breaking change but

Expose ESM entrypoint with Leaflet global (#8329 by @jonkoops)

can break something.

On the otherside how many will users will use the beta version and how long do we wait until the final release? I think as soon as possible would be good

[jonkoops]

I guess we can risk it, the ESM enablement was a hard one to get right in a backwards compatible manner. I have tested as many edge cases as possible, but you never know what kind of obscure cases can remain in the realm of users.

Should we just do a full release then? Just need to add a section to the release notes about ESM support and what it will mean going forward to the other module formats in v2 . Namely I'd like to remove UMD and disable globals by default (with an opt-in import to restore globals for incompatible plugins).

[jonkoops]

Alright, I have added a statement to the release notes that we can also add to the blog. @mourner @Falke-Design @Malvoz, can I ask y'all to take a look at it and give it a thumbs up?

[Malvoz]

@jonkoops That's a good summary. 👍🏻 But if the idea is to re-use that statement as a blog post for the v1.9 release in particular, isn't there too little focus on that version? Or were you thinking a standalone blog post? Either way, I personally don't mind it, just an observation.

[mourner]

@jonkoops great work on the statement! I made an edit pass, making it more compact and easier to digest.

[jonkoops]

But if the idea is to re-use that statement as a blog post for the v1.9 release in particular, isn't there too little focus on that version?

Yeah, I think you might be right. Besides, when we release 2.0 we will have plenty of time to explain the finer details.

[jonkoops]

Okay, I think we're good to go for a release. I'll get started.

[jonkoops]

Looks like I don't have the access to push directly to main, which makes sense. I've opened up a PR with the updates to the changelog (#8446). @mourner could you do the version bump and push it to main?

[Falke-Design]

@jonkoops my 2 cents to the release notes:
I would not preview Embracing modern JavaScript. for v2, because that change can cause that we need much longer then expected and wanted for the next release, if we don't get it finished.

[jonkoops]

Hmmmm, yeah I get the confusion. I meant to say that we would want to be able to use ES2015+ syntax, not necessarily that we're landing standardized classes in 2.0.

We could see if we can implement this in a backwards compatible way in a minor version, and then remove the legacy implementation in 3.0. But this requires further investigation.

We need to work out exactly what we want to deprecate and remove anyways, so none of this is set in stone just yet.

[mourner]

@jonkoops not at the laptop atm but will do tomorrow morning (and also take a look at permissions so you could push in future)

[mourner]

The release is out! Now pending updates to the docs/website. Dropping a checklist here before we close this out:

Releasing a new version of Leaflet

• Ensure all blocker Critical issue or PR that must be resolved before the next release issues and pull requests are resolved.
• Update the changelog since last release and commit.
• Run npm version <patch | minor | major> (this will bump the version in package.json and create a new tag).
• Run git push --follow-tags to push the commit created by NPM to Github (together with the tag).
• Wait for the CI to complete and follow the logs to make sure it runs successfully.
• Verify that the release was correctly published to NPM by checking:
  • Leaflet NPM package page
  • files on Leaflet unpkg page
• Make a new release on Leaflet's GitHub release page with the most important parts of the changelog

Updating docs after the release

• Make a new branch for the update
• Write a blog post about the new release and put it in /docs/_posts
• If necessary to preserve previous version's docs, rename dist/reference.html to dist/reference-X.Y.Z.html and add it to the list in docs/reference-versions.html
• Run npm run docs to generate the new docs/reference.html
• Run npm run integrity and make sure docs/_config.yml is updated with new hashes
• Update link to latest release in docs/download.md
• Update the announcement section in docs/index.html
• Commit all the changes and submit a PR for someone to review

[jonkoops]

Awesome, I went ahead and branched off the v1 branch so we can start merging breaking changes into main. Do we want to add a notice to the README that the 'legacy' code can be found on this branch and that this is the new v2 development version?

[jonkoops]

@mourner are you updating the docs, or would you like me to take a swing at it?

[mourner]

@jonkoops not updating docs yet — you're welcome to do so if you wish!

[jonkoops]

Let me take a look, I think it's good if I get familiar with the process.

[jonkoops]

@mourner PR for the release notes is here: #8453

[mourner]

We're done 🎉 Still need to follow up with v1.9.1 shortly it seems, but still, great work everyone.