Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Process Changes for 5.0 #1513

Closed
3 tasks done
heff opened this issue Sep 17, 2014 · 9 comments
Closed
3 tasks done

Process Changes for 5.0 #1513

heff opened this issue Sep 17, 2014 · 9 comments
Milestone

Comments

@heff
Copy link
Member

heff commented Sep 17, 2014

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.

  • 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.

  • 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.

  • 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.
@heff heff added this to the v5.0.0 milestone Sep 17, 2014
@gkatsev
Copy link
Member

gkatsev commented Sep 17, 2014

I would be for bumping major more frequently 😄

@albell
Copy link
Contributor

albell commented Sep 29, 2014

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
Copy link
Member Author

heff commented Sep 29, 2014

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

@space87
Copy link

space87 commented Oct 2, 2014

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
Copy link
Member

gkatsev commented Oct 2, 2014

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

@heff
Copy link
Member Author

heff commented Oct 2, 2014

@space87 did we break something specific for you?

@space87
Copy link

space87 commented Oct 27, 2014

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
Copy link
Member

mmcc commented Oct 27, 2014

@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
Copy link
Member Author

heff commented May 1, 2015

All tasks have been completed on this one.

@heff heff closed this as completed May 1, 2015
@github-actions github-actions bot locked as resolved and limited conversation to collaborators May 27, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

5 participants