Process Changes for 5.0

[heff]

An issue to gather thoughts on better process after the next major version. Feel free to comment other process thoughts

Versioning

We've been using Major and Minor versions as marketing milestones (i.e that's when we write blog posts) but that's creates a situation where we delay features to batch them together. After 5.0 we should disconnect the two, so versioning is independent of public communication. We could have a monthly status post instead.

We've also made breaking changes within minor release. We should move to a more Chrome/Firefox style of versioning where we bump the major version more frequently, or possibly move to ferver if that catches more steam. The thing to think about with all versioning decisions is how it affects plugin authors. Releasing breaking changes more often could make it hard for plugin authors to keep up. We've also broken a number of things for the Youtube plugin recently which wasn't great.

For a while I was releasing multiple changes in a single patch release. I'm moving back to a single change per patch release because for whatever reason that feels more accurate.

• [x] Document this somewhere? - Documented in the 5.0 changes wiki page

  Weekly Standup (IRC)

I'd like to have some form of checkin for the different core-related projects going on weekly. The jQuery team does a nice job of this with their Monday meetings, and it'd probably be good to copy some of that.

• [x] Create public calendar event

  Dist Folder Handling

We currently git-ignore the dist folder. There's positives and negatives to this listed in other issues, but I think we should unignore it so the compiled version of master can be used. We should not rely on the dist files for build processes, e.g. testing. Build files should go in the build folder. I think this will help avoid changes being made directly to the dist files. As a small additional change to this I'd like to change the /build/files directory to /build/temp to be more clear about what ends up in there.

• [x] Unignore dist folder Update: We're not going to unignore /dist, instead we've created a prerelease process that builds the dist after every push to master. Dist will never be in master or stable.

[gkatsev]

I would be for bumping major more frequently :smile:

[albell]

IMHO major releases should still get a blog post, minor are a case-by-case tossup, and patches can just go to a changelog. The problem is it's really subjective what is "major" and "minor" when it's breaking your site. Ferver doesn't really remove that ambiguity from semver, just relocates it.

Given that maintaining separate compatibility branches a la jQuery is realistically off the table, I think it's better for now to move fast and break things. Also, bumping major more frequently might make it easier for plugin authors to specify compatibility.

[heff]

Yeah, major would definitely still get a post. And I agree trying to manage two compatibility would be too much.

[space87]

Yer i think bumping the major versioning would be great just maybe a notice prior to release about what plugins you guys may think be affected so them authors can work on them

[gkatsev]

Not sure whether we could say specifically which plugins could be affected but we would definitely list explicitly any breaking changes.

[heff]

@space87 did we break something specific for you?

[space87]

Not that i know off, the only thing ive found is when videojs gets minifed you change the reference names of the variables from names to single letters like h or M or _e etc which is slightly annoying and causes me to use non min version in production. but know i was just saying if you know a list of breaking changes a list to plugin authors well in advance of release so we can get plugins fixed and working for the new version as close as it is ment to come out.

[mmcc]

@space87 As a general rule of thumb, you should never rely on any variable that's been minified. All of those change every time we create a new build, so the behavior you're seeing is entirely expected. If there are specific things you need that you can't get via something that's exported (ie, not munged during minification), you should let us know so we can expose that item (or help you come up with a workaround).

[heff]

All tasks have been completed on this one.