Release: push a custom slim build to the CDN

[timmywil]

• Adds a custom slim build with effects and ajax removed to the published artifacts.

Fixes gh-2653

[mgol]

Should we also modify the banner?

I wonder how we're going to support it. If we treat it just like the main jQuery file this means we can't remove anything else from this build before 4.0, right? Are we going to run tests on it on every commit or periodically?

[timmywil]

Should we also modify the banner?

It already will be. grunt custom adds notes about which modules were removed.

If we treat it just like the main jQuery file this means we can't remove anything else from this build before 4.0, right?

You mean remove other modules? Are there are other modules we want to remove from this build? I thought we had decided on ajax and effects. Also, this will be available for 3.0.

As for testing, we could set up a testswarm run and exclude ajax and effects tests, if that's not too much work.

[timmywil]

If we treat it just like the main jQuery file this means we can't remove anything else from this build before 4.0, right?

I think I understand what you're getting at now. If we wanted to remove more in upcoming versions of the slim build, I think that's okay as long as we document that future versions of slim may remove more modules that aren't used very much, and that can be indicated by the major version bump. For instance, we're not going to be "slimming down slim" even further between major versions, but users need to check on which modules are/aren't included when upgrading slim.

[dmethvin]

Should deprecated come out as well? I can't recall if we discussed that but it seems unlikely that someone who doesn't need ajax and effects would need the deprecated stuff.

[mgol]

We can't exclude deprecated. Semver allows us to deprecate stuff in minor releases but for the slim build it would mean removing which would be a breaking change. This would be too limiting to us.

We'd have to explicitlt say the slim build is experimental & unsupported and I'm not sure if that would be a good thing to do.

Michał Gołębiowski

[mgol]

(Note that this all means that if we detected an API was incorrectly e.g. in the core or css modules instead of effects we can't move it there before 4.0.0)

Michał Gołębiowski

[scottgonzalez]

We can't exclude deprecated. Semver allows us to deprecate stuff in minor releases but for the slim build it would mean removing which would be a breaking change. This would be too limiting to us.

I really don't think you should be deprecating anything in a minor release anyway. I would definitely remove the deprecated module in the slim build.

[dmethvin]

Seems like we could deprecate something documentation-wise in a minor but couldn't move it to deprecated.js until a major since that rearranges code in modules. It would still seem useful to exclude the current deprecated stuff (delegate and bind) in 3.0 if we could.

One other thing I thought about when #2712 was reported, we depend on $.ajax in _evalURL right now so if we exclude ajax that will mean script manipulation acts differently. If we move ahead and land #2126 we will always load the scripts async, but we still depend on $.ajax. (without a guard). Perhaps we need to just inject script tags in _evalURL?

[mgol]

@scottgonzalez

I really don't think you should be deprecating anything in a minor release anyway.

Why not? That's precisely what semver says to do.

@dmethvin

Seems like we could deprecate something documentation-wise in a minor but couldn't move it to deprecated.js until a major since that rearranges code in modules.

Spunds reasonable. We should put a big comment at the top of deprecated.js, though, to warn against moving stuff here between majors.

Note that we rearrange code all the time, not in a major way but new files are getting created, some things get moved etc. so we're not fully protected here. But maybe we shouldn't move stuff between top-level modules which would go along with your proposal.

[scottgonzalez]

Why not? That's precisely what semver says to do.

Historically, we've deprecated things in major releases and I think that's a good strategy. Semver just requires at least a minor version for deprecation.

[mgol]

Historically we haven't followed semver so it's hard to compare. Now that we require bumping the major when we break compatibility, deprecating something in a minor seems like a sensible choice. It allows to introduce new, better APIs without breaking the old ones and at the same time deprecating those old ones so that people may slowly migrate to the newer ones before they're ready to jump to a newer major. That's a strategy that Ember & QUnit take (correct me if I'm wrong, @leobalter) - if you migrate from deprecated APIs upgrading to a new major doesn't require any new changes - and I think it's valuable and we shouldn't restrict ourselves from using such a strategy.

EDIT: If we followed this strategy in Core & used explicit warnings for deprecated APIs, maybe we could get rid of Migrate in the future?

[timmywil]

I'd like to keep the warnings in migrate and documentation, but I agree that it can useful to have the freedom to deprecate things in minor releases.

[timmywil]

As for removing deprecated.js, I'm okay with that. Slim should not work differently than 3.0, but it can have things missing.

[leobalter]

That's right, @mzgol. The plans on QUnit releases are similar to Ember and we adapt the semver without breaking any rule.

Minor versions are up when we QUnit releases any new API feature. Major versions does not introduce any new feature or functionality. They just remove deprecated features. To remove them, we need to have the previous version sending warnings on the deprecated methods. That way, if you're able to run the last previous version without any warnings, you'll be able to run anything on the first next Major version without any problems.

If we followed this strategy in Core & used explicit warnings for deprecated APIs, maybe we could get rid of Migrate in the future?

I support this, a lot.

This worked pretty well on Ember from 1.x to 2.0 and I'm sure it will be very easy to migrate QUnit when we release 2.0.

[mgol]

As for removing deprecated.js, I'm okay with that. Slim should not work differently than 3.0, but it can have things missing.

Yes, as long as we don't move stuff there in minor/patch releases, even if we deprecate them, that sounds fine to me as well.

Note, though, that it won't change size of the slim build in any significant way before 4.0.0. Current deprecated.js is extremely small.

[mgol]

Thanks @leobalter for your explanation. The reasons you mentioned - i.e. the upgrade strategy of just getting rid of warnings and then updating to a newer major without any code changes is why I'd really love having those warnings directly in Core. But it seems I'm in the minority and it's too late for this discussion to influence jQuery 3.0 anyway.

[timmywil]

Note, though, that it won't change size of the slim build in any significant way before 4.0.0. Current deprecated.js is extremely small.

True, but I like starting with its removal up front, so that users are aware that the slim build gets deprecated stuff removed sooner than the full build. As someone who will probably use the slim build, I like that. It means I'm ahead of the curve.

And yes, we'd have to be careful about what we move to deprecated.js. So, we couldn't move things there just before a minor release. It would always have to be just before the next major.

Edit: that's not to say we can't deprecate things in minor versions. We just couldn't move deprecated code to deprecated.js until the major version bump.

[timmywil]

But it seems I'm in the minority and it's too late for this discussion to influence jQuery 3.0 anyway.

Bring this up again after 3.0 is released. :)

[timmywil]

I'll let this PR simmer another day before merging.

[leobalter]

Bring this up again after 3.0 is released. :)

It's a very good approach to start from 3.0. As soon as you release it, a documentation - and even a blog post - about the new release format would be delightful. And it's good to tell what users might expect on future releases of 3.0.0 and to watch for any warnings on the console.

[markelog]

Hmm, i'm not sure i understand what is happening here, first of all, when did we decide to do this? I mean i think this is a good idea and all, but

I thought we had decided on ajax and effects

this doesn't sound accurate, i don't remember we talked about this at the meeting, or maybe i missed something?

I'm not sure that this version could be called a "jQuery", since it would be distributed without proper functionality, it could be called a "jQuery slim" or something like that, but by the same name as other dist?

[timmywil]

i don't remember we talked about this at the meeting, or maybe i missed something

I know we talked about it, but it may not have been in the context of the weekly meeting. Perhaps it was at the summit? I forget.

I'm not sure that this version could be called a "jQuery", since it would be distributed without proper functionality, it could be called a "jQuery slim" or something like that, but by the same name as other dist?

It is a custom build of jQuery with some functionality removed. Remaining functionality is perfectly proper. It will have a different file name ("jquery.slim.js"), but I don't think it needs to be a separate distribution.

[mgol]

It's a very good approach to start from 3.0.

We want to release 3.0.0 soon so we're deferring any changes that might need extensive discussions and are not extremely needed to make into 3.0.0 to after the release. Adding warnings to Core could be done in a minor release so we're not in a hurry.

I thought we had decided on ajax and effects

this doesn't sound accurate, i don't remember we talked about this at the meeting, or maybe i missed something?

I remember it, we decided that at the summit. Maybe you weren't there then? You were late the first day.

[leobalter]

We want to release 3.0.0 soon so we're deferring any changes that might need extensive discussions and are not extremely needed to make into 3.0.0 to after the release. Adding warnings to Core could be done in a minor release so we're not in a hurry.

I only tried to say it's a good idea to start the release w/ warnings process after the 3.0 release. It does not prevent or block anything. The release approach should take effect after it's released, so we may document we need to log a warning on every deprecation after 3.0.

[markelog]

It will have a different file name ("jquery.slim.js"), but I don't think it needs to be a separate distribution.

Well, it has separate distribution, since it is distributed through CDN as a whole, without the ability to acquire other parts of it.

But it is something entirely different then "jQuery" since it has different API and logic of what is distributed is what semver trying to standardize.

[mgol]

But it is something entirely different then "jQuery" since it has different API and logic of what is distributed is what semver trying to standardize.

If we distribute it together with the main jQuery (which is the current plan) then it shares its versioning so all semver-related concerns apply to the slim build as well.

[timmywil]

But it is something entirely different then "jQuery" since it has different API and logic

It doesn't have different logic in the same sense as compat had different logic. It is a subset of the same API and logic. Practically speaking, I want users to be able to pull "jquery" down from bower and npm and use the "slim" custom build. It would be the same thing as cloning the jquery repo and making the slim build themselves, but more convenient.

[markelog]

I'm not sure if i do understand still, this PR titled as a "push a custom slim build to the CDN", so it will be distributed through CDN right? If so, then it looks like it is violating the semver

[markelog]

Practically speaking, I want users to be able to pull "jquery" down from the bower and npm and use the "slim" custom build.

That would be okay, since you also distrubuting the full version, but with CDN you are not

[timmywil]

I'm not sure if i do understand still, this PR titled as a "push a custom slim build to the CDN", so it will be distributed through CDN right? If so, then it looks like it is violating the semver.

This PR doesn't actually push anything to the CDN. It enables the release script to push a slim build to the CDN when we release.

[markelog]

This PR doesn't actually push anything to the CDN. It enables the release script to push a slim build to the CDN when we release.

Well, it doesn't really matter "when" it will be at the CDN, if it will, then i see an issue

[timmywil]

Well, it doesn't really matter "when" it will be in the CDN, if it will, then i see an issue

I don't see how. The full build is still there under "jquery.js". You'd have to change the path to "jquery.slim.js".

[timmywil]

Perhaps it wasn't clear that this doesn't change the full build's distribution to the CDN?

[markelog]

The way how code is distributed is matter i think, in my point of view npm install is the same as HTTP request to the CDN. So npm install <package> === one HTTP request.

I don't know, maybe i'm alone in this thought, if no one else thinks the same then perhaps it just a philosophy of one i.e. shouldn't matter.

[mgol]

@markelog I disagree. I don't see anything bad about more than one module being available in one npm package. We already publish both src/ and the built file, both minified & unminified which is already a duplication of some sorts. And since it's simpler for us to distribute it that way, I don't see a problem with having both built files in one package.

[markelog]

I disagree. I don't see anything bad about more than one module being available in one npm package.

That is not what i was saying, i don't see anything bad with the npm distribution - you install the package, you get full version, if you want to strip it, cool, user choice.

But i see the issue however, in the HTTP request which should give the user full version of API as advertised by the name of "jQuery", but instead, user would have the entirely different thing.

[markelog]

In other words, if we call it a "jQuery slim" which included in the "jQuery" package, that is okay. But if we call it "jQuery" but instead provide something different, that is not (to me that is).

[markelog]

That, in turn, would mean that is a different lib, like "jQuery" is not the same as "jQuery Compat" would have been.

[mgol]

But if we call it "jQuery"

The file will be named jquery.slim.js; "Slim" doesn't appear anywhere else.

In any case, I don't understand the comparison with CDNs, those things don't really have much in common. You create script tags linked to single files on the CDN whereas you install npm packages (this process has nothing to do with HTML). An npm package is a directory with a set of files, a file from CDN is... a single file.

[markelog]

I don't understand the comparison with CDNs, those things don't really have much in common.

Those are different ways of distribution of the code, of the same code. In our case, with CDN, users will get different version of it, with npm they will not. So yeah -

An npm package is a directory with a set of files, a file from CDN is... a single file.

exactly. That "signle file" supposed to provide the same API.

[markelog]

Like ember was mentioned here, with npm, bower or CDN you will get exactly same version of the ember API, we on the other hand, trying to distributed different code under the same name.

[mgol]

In our case, with CDN, users will get different version of it, with npm they will not.

I don't think I understand. With the Google CDN you'll ask for one of:

1. https://ajax.googleapis.com/ajax/libs/jquery/3.0.0/jquery.min.js
2. https://ajax.googleapis.com/ajax/libs/jquery/3.0.0/jquery.slim.min.js

Via npm you'll use the jquery package and use either the jquery.min.js file or the jquery.slim.min.js one. What's different there?

[markelog]

I don't think I understand. With the Google CDN you'll ask for one of:

I that would be two different versions, with npm you would have one. You might ask the same question with -

1. https://ajax.googleapis.com/ajax/libs/jqueryui/1.5.2/jquery-ui.min.js
2. https://ajax.googleapis.com/ajax/libs/jquery/1.5.2/jquery.min.js

Those are different libs, just like with your items, npm package is, however, distributed as one whole solid thing a "package", with URL address, on the other hand, one impartible entity is HTTP request.

If your practise would be applicable, we could have remove the banner from source and use something like that - https://ajax.googleapis.com/ajax/libs/jquery/3.0.0/LICENSE.txt

But we can't, for same reasons.

[markelog]

But i want to emphasise, that this might only my distorted point of view. If no one sharing it, we could move on.

[timmywil]

Yea, thank you all for the debate, but let me just call it here and say we're going to distribute jquery slim in the jquery package.

[markelog]

ok-ok

[dmethvin]

I'm good with the plan, it's just a subset of the same functionality. Nobody will get it by accident and we can be sure to only make breaking changes to it on major semver bumps.