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

Remove the "Beta" release label? #4898

Closed
jasongrout opened this issue Jul 13, 2018 · 9 comments
Closed

Remove the "Beta" release label? #4898

jasongrout opened this issue Jul 13, 2018 · 9 comments

Comments

@jasongrout
Copy link
Contributor

@jasongrout jasongrout commented Jul 13, 2018

I think we are being somewhat ineffective in communicating to users that JupyterLab is ready for use. I propose that we drop the "Beta" label on releases, but still keep the pre-1.0 version number. We've had discussions and disagreements about whether we want to release 1.0 or not, and I think this strikes a nice balance of communicating what we want to the different audiences we are addressing.

As a huge generalization, users seem to pay attention to the words, while developers seem to pay attention to the more precise and semantically meaningful version numbers. If we want to communicate to users that JLab is ready for use, I think we should drop the "Beta" label. If we want to communicate to developers that we are still stabilizing the extension api, and breaking changes are coming every 4-6 weeks with a new 0.x release, we should keep the pre-1.0 version numbers. I think we want to do both, so I propose we call the next release just JupyterLab 0.33.

I think we have done a lot of polishing since February, so I think it was still valuable to have a "beta" release period up to this point.

What do you think? Are there some important polish issues to address before dropping the beta label?

@blink1073
Copy link
Member

@blink1073 blink1073 commented Jul 14, 2018

My preference would be for 0.34 to also include 1.0+ releases of all of the JavaScript packages. That gives us more semver space to make additive changes across the board while making it less painful for extension authors. The top level message is still that that overall application is not yet 1.0.

@afshin
Copy link
Member

@afshin afshin commented Jul 17, 2018

I think we should drop the "Beta" label.

I am 👍 on this.

My preference would be for 0.34 to also include 1.0+ releases of all of the JavaScript packages.

I am 👍 on this.

The top level message is still that that overall application is not yet 1.0.

I am 👎 on this.

@jasongrout
Copy link
Contributor Author

@jasongrout jasongrout commented Jul 17, 2018

The top level message is still that that overall application is not yet 1.0.

I am 👎 on this.

Just to clarify, @afhsin, are you 👍 on making the overall application 1.0?

@afshin
Copy link
Member

@afshin afshin commented Jul 17, 2018

Sorry, I was being a little facetious here. I agree with removing the beta wording in the codebase, the docs, and the way we talk about JupyterLab. I don't believe our actual version number should change.

@ian-r-rose
Copy link
Member

@ian-r-rose ian-r-rose commented Jul 17, 2018

I agree that we can remove the "Beta" branding. I am agnostic about whether we should go to 1.0 in all of the packages. I practice we will be doing semver-major version bumps for a while yet, but I don't think it matters much to us or to extension authors whether they are pre or post 1.0.

@ellisonbg
Copy link
Contributor

@ellisonbg ellisonbg commented Jul 17, 2018

I am +1 on removing the beta branding. On the versioning side, I don't know that it makes a huge difference either way as long as we follow semver. However, there may be specific reasons that individuals or organizations have for wanting or not wanting to call a particular release 1.0.

@jasongrout
Copy link
Contributor Author

@jasongrout jasongrout commented Jul 17, 2018

Okay, I'll put in an issue to remove the Beta branding for 0.33, which is the least disruptive of these changes.

I'm -1 on bumping all packages to 1.0 for jlab 0.33 this close to a release. I think we should evaluate moving individual packages to 1.0 on a case-by-case basis (i.e., if we feel like a package is pretty stable at this point, go ahead, but if we know of some major changes in the pipeline we'd like to make, no reason to rush to 1.0 for that particular package).

@jasongrout
Copy link
Contributor Author

@jasongrout jasongrout commented Jul 17, 2018

I'll put in an issue to remove the Beta branding for 0.33

Actually, that's this issue :).

jasongrout added a commit to jasongrout/jupyterlab that referenced this issue Jul 18, 2018
@blink1073 blink1073 closed this in 2e5b00c Jul 19, 2018
jasongrout added a commit to jasongrout/jupyterlab that referenced this issue Jul 27, 2018
@SimonBiggs
Copy link
Member

@SimonBiggs SimonBiggs commented Aug 3, 2018

#4898 (comment)

My preference would be for 0.34 to also include 1.0+ releases of all of the JavaScript packages. That gives us more semver space to make additive changes across the board while making it less painful for extension authors. The top level message is still that that overall application is not yet 1.0.

I know that I would personally appreciate a semver signal within the JavaScript libraries that a breaking change has occured. It would mean, should a JavaScript dependency bump a major version then I need to go and track down the breaking changes for that particular version.

In saying that, I do really appreciate the work gone into detailing the change logs.

An example is, I have really appreciated having many of phosphor's libraries go 1.0.0+ as I am now willing to use those in a wider range of projects.

But if rapid development and API instability for those libraries is still in place then I concede that it should still be 0.x.y

@lock lock bot locked as resolved and limited conversation to collaborators Aug 8, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
6 participants