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

Future of Versioning #4950

Closed
hzoo opened this Issue Dec 7, 2016 · 1 comment

Comments

Projects
None yet
2 participants
@hzoo
Member

hzoo commented Dec 7, 2016

https://github.com/babel/notes/blob/master/2016-07/july-31.md#future-of-babels-release-process-and-its-ecosystem

  • Independent/Fixed mode in Lerna
  • What to do about breaking changes?
  • How to help plugins/users update (codemods?)
  • How to communicate breaking changes
  • How to manage experimental syntax in the parser
  • How to manage experimental plugins
  • How to do canary builds/prereleases

@hzoo hzoo added the i: discussion label Dec 7, 2016

@xtuc

This comment has been minimized.

Show comment
Hide comment
@xtuc

xtuc Dec 16, 2016

Member

I would like to help with my thought about this. I might not have the full context.
Please correct me if I'm wrong.

Independent/Fixed mode in Lerna

  • I don't know Lerna much but each plugin should be indepedent from Babel.

What to do about breaking changes?

  • We need BC to be able to add new features or fix bugs
  • Document changes

How to help plugins/users update (codemods?)

  • Babel should expose its version to plugin implementors
    • Example
      if (babel.VERSION > 5) {
        // a
      } else {
        // b
      }
  • Documentation about BC should be explicit
  • Using git tags preset-a@5 will help the user but avoid update for a while
  • I like Flowtype, we could provide some definitions for specific versions?
  • Node provides nan (Native Abstractions for Node) which abstract the v8 API (had BC quite a lot)
    • I think Babel does need this because we are talking about Babel's org packages.
  • Babel-types could expose multiple versions
    import t from "babel-types/v4"

How to communicate breaking changes

  • CHANGELOG
  • Document how to upgrade to version X
  • We could log deprecated behaviors (if NODE_ENV is test)

How to manage experimental syntax in the parser

  • Flags to Babel, like c++ does to enable lambda syntax -std=c++11

How to manage experimental plugins

  • Create a seperate repo with experimental plugins
    babel --plugins experimental-scala-syntax
    • Once the plugin stable, it could be copied and renamed to the main repo (babel/babel)
      • Works also with legacy plugins (babel/babel-archives)

How to do canary builds/prereleases

  • Built the release with specific flag/version name
  • Don't publish it to npm

Aside notes

  • symfony/symfony is a very good example.
    • The promise of backward compatibility
    • Good documentation about BC
    • Internal components doesn't conflicts
    • Bundle are registered and accessed using services which are less impacted with BC

/cc @loganfsmyth what do you think about this?

Member

xtuc commented Dec 16, 2016

I would like to help with my thought about this. I might not have the full context.
Please correct me if I'm wrong.

Independent/Fixed mode in Lerna

  • I don't know Lerna much but each plugin should be indepedent from Babel.

What to do about breaking changes?

  • We need BC to be able to add new features or fix bugs
  • Document changes

How to help plugins/users update (codemods?)

  • Babel should expose its version to plugin implementors
    • Example
      if (babel.VERSION > 5) {
        // a
      } else {
        // b
      }
  • Documentation about BC should be explicit
  • Using git tags preset-a@5 will help the user but avoid update for a while
  • I like Flowtype, we could provide some definitions for specific versions?
  • Node provides nan (Native Abstractions for Node) which abstract the v8 API (had BC quite a lot)
    • I think Babel does need this because we are talking about Babel's org packages.
  • Babel-types could expose multiple versions
    import t from "babel-types/v4"

How to communicate breaking changes

  • CHANGELOG
  • Document how to upgrade to version X
  • We could log deprecated behaviors (if NODE_ENV is test)

How to manage experimental syntax in the parser

  • Flags to Babel, like c++ does to enable lambda syntax -std=c++11

How to manage experimental plugins

  • Create a seperate repo with experimental plugins
    babel --plugins experimental-scala-syntax
    • Once the plugin stable, it could be copied and renamed to the main repo (babel/babel)
      • Works also with legacy plugins (babel/babel-archives)

How to do canary builds/prereleases

  • Built the release with specific flag/version name
  • Don't publish it to npm

Aside notes

  • symfony/symfony is a very good example.
    • The promise of backward compatibility
    • Good documentation about BC
    • Internal components doesn't conflicts
    • Bundle are registered and accessed using services which are less impacted with BC

/cc @loganfsmyth what do you think about this?

@hzoo hzoo referenced this issue Jan 26, 2017

Closed

[7.0] Use lerna's --independent mode + changes #5221

0 of 7 tasks complete

@hzoo hzoo closed this Jan 26, 2017

@lock lock bot added the outdated label May 5, 2018

@lock lock bot locked as resolved and limited conversation to collaborators May 5, 2018

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.