Yikes, thanks for the report!

@timmywil This file shouldn't even exist in this version; it seems like the release was done on a non-fresh clone of the repo with files built from master which seems weird as jquery-release runs it all on a fresh repo clone... How did it happen?

Marking it as a blocker so that we don't have extra files from a different beta version in 2.2.4.

The same applies to 1.12.3.

Oh, I know how it happened. It pushed to dist and ran publish from the dist repo, which had slim files sitting there from previous commits.

Ah, OK. I guess the fix that would kill similar issues in the future would be to git rm -r dist before adding new files?

Were you using a local clone of jquery for the build? If you were using --remote=jquery/jquery, you should have been publishing from a fresh clone of jquery-dist (based on a quick glance at your release script).

@scottgonzalez It was a fresh clone, but it didn't overwrite the slim files.

Another solution (probably simpler), would be to add those files to the .npmignore/bower.json ignore on non-master branches.

Another solution (probably simpler), would be to add those files to the .npmignore/bower.json ignore on non-master branches.

That's not future-proof. I think we should ensure dist contains only what's generated in the current build.

Ok, perhaps a whilelist instead of a blacklist (files property).

I don't want to remove the whole dist before copying. This wouldn't work on windows, but rsync has a feature that removes files that aren't being copied over.

While you are at it, can you fix the versions in the .map files too? They all state that they are version 3.

@beruic "version": 3 in the source map file means it uses the 3rd version of the source map spec (i.e. the latest one) so that's fine. Unless you're talking about sth else?

Good work you guys 👏🏼🎉

On 13. mai 2016, at 17:38, Timmy Willison notifications@github.com wrote:

Closed #3094 via 95c7ab6.

—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub

On CDNjs the slim files still have v3.0.0-beta1 in the header.

@beruic if you mean the 2.2.3 files, we don't remove and republish files that have already been published elsewhere. Think of something like that as a force-push to a public repo here at Github, it's pretty disruptive. In many cases it would not even work, CDNs set long expiration dates for the cached files so browsers and proxies will pull from their cache regardless of whether the file has been updated or removed.

The fix committed here was for our release process to be sure the problem did not happen in the future. We've got a new release coming in the next couple of days.