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

Warning about not using a pre-release version. #6004

Closed
jcoyne opened this Issue Sep 5, 2017 · 41 comments

Comments

Projects
None yet
@jcoyne

jcoyne commented Sep 5, 2017

When I run bundle install I get this message:

$ bundle install
The latest bundler is 1.16.0.pre.1, but you are currently running 1.15.4.

I don't think it should give me a warning about not using a pre-release.

@segiddins

This comment has been minimized.

Show comment
Hide comment
@segiddins

segiddins Sep 5, 2017

Member

It's just a message, you're free to ignore it, but we want to give people the opportunity to try out pre-releases before their final release

Member

segiddins commented Sep 5, 2017

It's just a message, you're free to ignore it, but we want to give people the opportunity to try out pre-releases before their final release

@indirect

This comment has been minimized.

Show comment
Hide comment
@indirect

indirect Sep 5, 2017

Member

Maybe we could change the message a bit to make it more friendly for prereleases:

  • disable the notice if the new version is a prerelease and the install is --deployment mode
  • add to the notice if the new version is a prerelease “Don’t install this prerelease in production environments.”
  • add to the notice, after the install instructions: “Disable this message by running bundle config disable_update_message true

Current message:

The latest bundler is 1.16.0.pre.1, but you are currently running 1.15.4.
To update, run gem install bundler --pre

Potential message for prerelease, in non-deployment mode:

The latest bundler is 1.16.0.pre.1, but you are currently running 1.15.4.
Help us test the next version of Bundler in your development environment! Please wait to upgrade production servers until the final release. Read about what changed at https://github.com/bundler/bundler/releases/v1.16.0. To disable these update alerts, run bundle config disable_update_alerts true. To update, run gem install bundler --pre.

Potential message for a regular release:

The latest bundler is 1.16.0, but you are currently running 1.15.4.
Read about what changed at https://github.com/bundler/bundler/releases/v1.16.0. To disable these update alerts, run bundle config disable_update_alerts true. To update, run gem install bundler --pre.

(no message at all for prerelease + deployment mode)

Member

indirect commented Sep 5, 2017

Maybe we could change the message a bit to make it more friendly for prereleases:

  • disable the notice if the new version is a prerelease and the install is --deployment mode
  • add to the notice if the new version is a prerelease “Don’t install this prerelease in production environments.”
  • add to the notice, after the install instructions: “Disable this message by running bundle config disable_update_message true

Current message:

The latest bundler is 1.16.0.pre.1, but you are currently running 1.15.4.
To update, run gem install bundler --pre

Potential message for prerelease, in non-deployment mode:

The latest bundler is 1.16.0.pre.1, but you are currently running 1.15.4.
Help us test the next version of Bundler in your development environment! Please wait to upgrade production servers until the final release. Read about what changed at https://github.com/bundler/bundler/releases/v1.16.0. To disable these update alerts, run bundle config disable_update_alerts true. To update, run gem install bundler --pre.

Potential message for a regular release:

The latest bundler is 1.16.0, but you are currently running 1.15.4.
Read about what changed at https://github.com/bundler/bundler/releases/v1.16.0. To disable these update alerts, run bundle config disable_update_alerts true. To update, run gem install bundler --pre.

(no message at all for prerelease + deployment mode)

@mtgrosser

This comment has been minimized.

Show comment
Hide comment
@mtgrosser

mtgrosser Sep 6, 2017

Bundler gets more annoying with every release. As a developer and administrator, I decide when to upgrade gems and other depedencies. If you want to "inform" your users, start an email newsletter or put it on your blog, instead of cluttering everyday tasks with color-highlighted null-information.

mtgrosser commented Sep 6, 2017

Bundler gets more annoying with every release. As a developer and administrator, I decide when to upgrade gems and other depedencies. If you want to "inform" your users, start an email newsletter or put it on your blog, instead of cluttering everyday tasks with color-highlighted null-information.

@segiddins

This comment has been minimized.

Show comment
Hide comment
@segiddins

segiddins Sep 6, 2017

Member

Feel free to disable the message with bundle config disable_version_check true, but it won't be going away. As we're a small team, we don't have the resources to maintain old versions. We literally have no way of helping our users if they're not staying up to date with the latest bundler versions, and this already is the compromise option -- see what tools like fastlane and brew do, which is auto-updating, which I'm sure you'd find more annoying than a couple of lines of text output

Member

segiddins commented Sep 6, 2017

Feel free to disable the message with bundle config disable_version_check true, but it won't be going away. As we're a small team, we don't have the resources to maintain old versions. We literally have no way of helping our users if they're not staying up to date with the latest bundler versions, and this already is the compromise option -- see what tools like fastlane and brew do, which is auto-updating, which I'm sure you'd find more annoying than a couple of lines of text output

@Odaeus

This comment has been minimized.

Show comment
Hide comment
@Odaeus

Odaeus Sep 8, 2017

I think most people don't mind having an upgrade notice but telling the entire bundler user base to upgrade to a pre-release version is perhaps not suitable. As an experienced developer I found the message confusing. I think less experienced developers will believe they must upgrade to it and then won't understand why something breaks.

@indirect's solution seems good, though I would have a different flag to disable notifications about pre-release versions.

Odaeus commented Sep 8, 2017

I think most people don't mind having an upgrade notice but telling the entire bundler user base to upgrade to a pre-release version is perhaps not suitable. As an experienced developer I found the message confusing. I think less experienced developers will believe they must upgrade to it and then won't understand why something breaks.

@indirect's solution seems good, though I would have a different flag to disable notifications about pre-release versions.

@gshutler

This comment has been minimized.

Show comment
Hide comment
@gshutler

gshutler Sep 11, 2017

It would be enough for me if the message for pre-release versions wasn't yellow.

gshutler commented Sep 11, 2017

It would be enough for me if the message for pre-release versions wasn't yellow.

@bobvanderlinden

This comment has been minimized.

Show comment
Hide comment
@bobvanderlinden

bobvanderlinden Sep 11, 2017

I was new to bundler and this warning surprised me. At this time it's hard to know what trouble I will get myself into running a pre-release of bundler. However, I do want to keep bundler up-to-date with the latest stable version. I'd imagine this is a common scenario.

Doing a bundle config disable_version_check true would disable version checks as a whole (pre-releases and stable releases). It would be helpful to have an option to disable pre-release checks (disable_prerelease_version_check?) in addition to mentioning this option when bundler shows the suggestion (like @indirect suggests).

bobvanderlinden commented Sep 11, 2017

I was new to bundler and this warning surprised me. At this time it's hard to know what trouble I will get myself into running a pre-release of bundler. However, I do want to keep bundler up-to-date with the latest stable version. I'd imagine this is a common scenario.

Doing a bundle config disable_version_check true would disable version checks as a whole (pre-releases and stable releases). It would be helpful to have an option to disable pre-release checks (disable_prerelease_version_check?) in addition to mentioning this option when bundler shows the suggestion (like @indirect suggests).

@tomstuart

This comment has been minimized.

Show comment
Hide comment
@tomstuart

tomstuart Sep 11, 2017

It makes perfect sense to warn about new stable versions, but I don’t understand your motivation for encouraging every Bundler user to upgrade to a prerelease.

I would expect the best prerelease audience to be experienced users who know how to report bugs effectively and roll back to a stable release if they hit a serious problem. These users also understand what a prerelease is and are able to judge whether now is a good time to try one out.

Conversely, less experienced users are more likely to assume that all warnings are important, and therefore to type the recommended command to “fix it” regardless of how appropriate that is, which then leaves them in a situation where Bundler is presumably a little more likely to be broken because of unexpected teething problems. They may not know enough to back themselves out of this situation.

For that reason I believe the warning about prereleases should be opt-in for experienced users who are interested in testing new versions, not opt-out, and certainly not at the coarse granularity of “I never want to see any upgrade notices”.

tomstuart commented Sep 11, 2017

It makes perfect sense to warn about new stable versions, but I don’t understand your motivation for encouraging every Bundler user to upgrade to a prerelease.

I would expect the best prerelease audience to be experienced users who know how to report bugs effectively and roll back to a stable release if they hit a serious problem. These users also understand what a prerelease is and are able to judge whether now is a good time to try one out.

Conversely, less experienced users are more likely to assume that all warnings are important, and therefore to type the recommended command to “fix it” regardless of how appropriate that is, which then leaves them in a situation where Bundler is presumably a little more likely to be broken because of unexpected teething problems. They may not know enough to back themselves out of this situation.

For that reason I believe the warning about prereleases should be opt-in for experienced users who are interested in testing new versions, not opt-out, and certainly not at the coarse granularity of “I never want to see any upgrade notices”.

@segiddins

This comment has been minimized.

Show comment
Hide comment
@segiddins

segiddins Sep 11, 2017

Member

👎🏻. Not enough people install Bundler betas as is, and then people get angry when we release a stable version that has regressions. We can't guarantee a stable release will be stable unless a larger portion of the community helps us test the prereleases, and we certainly won't get more beta testers if they don't know there's a beta to test!

Member

segiddins commented Sep 11, 2017

👎🏻. Not enough people install Bundler betas as is, and then people get angry when we release a stable version that has regressions. We can't guarantee a stable release will be stable unless a larger portion of the community helps us test the prereleases, and we certainly won't get more beta testers if they don't know there's a beta to test!

@agorf

This comment has been minimized.

Show comment
Hide comment
@agorf

agorf Sep 11, 2017

Prompting users to upgrade to a pre version without warning them that this may break their system (not all users of bundler know this) will only backfire when users start complaining that a) bundler broke their system and b) the thing that started it all was an official upgrade prompt from the software itself.

Getting more testers is an understandable need for any open source project, but this is the wrong way to do it.

If kept, the message should at least warn what upgrading to a pre version means.

agorf commented Sep 11, 2017

Prompting users to upgrade to a pre version without warning them that this may break their system (not all users of bundler know this) will only backfire when users start complaining that a) bundler broke their system and b) the thing that started it all was an official upgrade prompt from the software itself.

Getting more testers is an understandable need for any open source project, but this is the wrong way to do it.

If kept, the message should at least warn what upgrading to a pre version means.

@tomstuart

This comment has been minimized.

Show comment
Hide comment
@tomstuart

tomstuart Sep 11, 2017

@segiddins Okay, understood. I still think that encouraging inexperienced users to install a beta to fix a warning is likely to lead to more pain for the Bundler team in the long run, but I accept that it’s your risk to take.

tomstuart commented Sep 11, 2017

@segiddins Okay, understood. I still think that encouraging inexperienced users to install a beta to fix a warning is likely to lead to more pain for the Bundler team in the long run, but I accept that it’s your risk to take.

@Odaeus

This comment has been minimized.

Show comment
Hide comment
@Odaeus

Odaeus Sep 11, 2017

@segiddins trying to get more users to test the beta version is a perfectly valid intention. I don't understand why you are opposed to changing the message to explicitly explain that it is a beta version? Yes, many people won't upgrade if they know that, but it's likely you will still get many new pre-release users.

I would suggest it is better to increase the pool by a smaller number of testers through goodwill than a larger number through confusion.

Odaeus commented Sep 11, 2017

@segiddins trying to get more users to test the beta version is a perfectly valid intention. I don't understand why you are opposed to changing the message to explicitly explain that it is a beta version? Yes, many people won't upgrade if they know that, but it's likely you will still get many new pre-release users.

I would suggest it is better to increase the pool by a smaller number of testers through goodwill than a larger number through confusion.

@dgpokl

This comment has been minimized.

Show comment
Hide comment
@dgpokl

dgpokl Sep 11, 2017

@segiddins Is the solution to "not enough people installing the betas" really to kinda-sorta trick less sophisticated users into inadvertently joining the beta program by presenting them with this "Warning: you'd better upgrade to an unstable beta!" message? In effect, by advertising the pre version in this way – with nothing but the 3 letters "pre" to explain what this new version even is, you're actually making the "pre" version a de facto release version. At least by changing the message you could achieve the results you desire without accidentally ensnaring new users, who aren't going to be useful beta users anyway. They aren't going to know how to revert to the stable version, let alone where to go to report bugs, and how to create a useful bug report.

A new beta of bundler is available (1.16.0.pre.2). You are currently running 1.15.4.
If you would like to help us make Bundler better, run `gem install bundler --pre`
If you have any trouble please report bugs at http://...
To go back to the previous stable version of bundler, run `gem install bundler -v 1.15.4`

dgpokl commented Sep 11, 2017

@segiddins Is the solution to "not enough people installing the betas" really to kinda-sorta trick less sophisticated users into inadvertently joining the beta program by presenting them with this "Warning: you'd better upgrade to an unstable beta!" message? In effect, by advertising the pre version in this way – with nothing but the 3 letters "pre" to explain what this new version even is, you're actually making the "pre" version a de facto release version. At least by changing the message you could achieve the results you desire without accidentally ensnaring new users, who aren't going to be useful beta users anyway. They aren't going to know how to revert to the stable version, let alone where to go to report bugs, and how to create a useful bug report.

A new beta of bundler is available (1.16.0.pre.2). You are currently running 1.15.4.
If you would like to help us make Bundler better, run `gem install bundler --pre`
If you have any trouble please report bugs at http://...
To go back to the previous stable version of bundler, run `gem install bundler -v 1.15.4`
@ilude

This comment has been minimized.

Show comment
Hide comment
@ilude

ilude Sep 11, 2017

@segiddins warning level messages are for warnings! I expect my team to watch for them and fix them. But my devs are not here to beta test your software. There is no danger in my team using the stable release, but now I have to explain to all of them why they are seeing this and what it means and why they should ignore it. So while I respect that your time is limited and valuable, so is mine, and so is the time of the rest of the folks here telling you that this is a mistake.

Please do not take this as a personal attack, it's not. I and I think everyone else here respects the bundler team and the time and effort they put into this. This change is a mistake and its not the right way to accomplish what you want to do. You have to understand that your software gets used by a lot of people in a lot of ways. And when many of those people provide you with valuable feedback the proper paraphrased response is not: we have to break your work flow so that we get enough beta testers. My production pipeline is not the place to beta test your software!

ilude commented Sep 11, 2017

@segiddins warning level messages are for warnings! I expect my team to watch for them and fix them. But my devs are not here to beta test your software. There is no danger in my team using the stable release, but now I have to explain to all of them why they are seeing this and what it means and why they should ignore it. So while I respect that your time is limited and valuable, so is mine, and so is the time of the rest of the folks here telling you that this is a mistake.

Please do not take this as a personal attack, it's not. I and I think everyone else here respects the bundler team and the time and effort they put into this. This change is a mistake and its not the right way to accomplish what you want to do. You have to understand that your software gets used by a lot of people in a lot of ways. And when many of those people provide you with valuable feedback the proper paraphrased response is not: we have to break your work flow so that we get enough beta testers. My production pipeline is not the place to beta test your software!

@segiddins

This comment has been minimized.

Show comment
Hide comment
@segiddins

segiddins Sep 11, 2017

Member

we have to break your work flow so that we get enough beta testers

I'm sorry, could you clarify how this change actually broke your workflow?

Member

segiddins commented Sep 11, 2017

we have to break your work flow so that we get enough beta testers

I'm sorry, could you clarify how this change actually broke your workflow?

@ilude

This comment has been minimized.

Show comment
Hide comment
@ilude

ilude Sep 11, 2017

bundle install is part of our workflow. Your message is a warning level message, as I stated I expect my team to fix warnings. A warning is an error, a warning is a broken build. Clean builds do not produce warnings. To fix this they have to deploy a pre-release version of bundler. Pre-release versions are not to be used unless it fixes a known issue that is affecting our production workflow. There are no issues that the 1.16 pre release addresses for my production workflow.

I understand that you think its not a big deal, but it is. I have my team trained to fix warnings, you are coming in and telling them to ignore warnings. The issue is not the message, the issue is the way you are displaying the message. It is not a warning! It is a suggestion! I'm fine with the suggestion, I'm not fine with you taking a standard part of my workflow and using it to suggest things that are not acceptable.

ilude commented Sep 11, 2017

bundle install is part of our workflow. Your message is a warning level message, as I stated I expect my team to fix warnings. A warning is an error, a warning is a broken build. Clean builds do not produce warnings. To fix this they have to deploy a pre-release version of bundler. Pre-release versions are not to be used unless it fixes a known issue that is affecting our production workflow. There are no issues that the 1.16 pre release addresses for my production workflow.

I understand that you think its not a big deal, but it is. I have my team trained to fix warnings, you are coming in and telling them to ignore warnings. The issue is not the message, the issue is the way you are displaying the message. It is not a warning! It is a suggestion! I'm fine with the suggestion, I'm not fine with you taking a standard part of my workflow and using it to suggest things that are not acceptable.

@segiddins

This comment has been minimized.

Show comment
Hide comment
@segiddins

segiddins Sep 11, 2017

Member

You can always disable the warning if you don't like it!

Member

segiddins commented Sep 11, 2017

You can always disable the warning if you don't like it!

@ilude

This comment has been minimized.

Show comment
Hide comment
@ilude

ilude Sep 11, 2017

So let me get this straight, your reason for putting this in is that your not getting enough beta participation? You solution is to turn off this messaging for all future release updates that may in fact fix serious issues?

This is the equivalent of using the fire alarm to get everyone's attention in the theater to tell them about the new awesome popcorn you are selling. And when people complain about you using the fire alarm that way you suggestion is to turn off the fire alarm entirely?

Are you serious?!?

ilude commented Sep 11, 2017

So let me get this straight, your reason for putting this in is that your not getting enough beta participation? You solution is to turn off this messaging for all future release updates that may in fact fix serious issues?

This is the equivalent of using the fire alarm to get everyone's attention in the theater to tell them about the new awesome popcorn you are selling. And when people complain about you using the fire alarm that way you suggestion is to turn off the fire alarm entirely?

Are you serious?!?

@ntl

This comment has been minimized.

Show comment
Hide comment
@ntl

ntl Sep 11, 2017

Not enough people install Bundler betas as is, and then people get angry when we release a stable version that has regressions. We can't guarantee a stable release will be stable unless a larger portion of the community helps us test the prereleases, and we certainly won't get more beta testers if they don't know there's a beta to test!

Once you tell end users to download and use a newer version via a warning, that version is now effectively an official release. That warning message supersedes any prerelease caveat you put into the version string. If another software provider told any one of us, "use version Y, not X," we would infer that we're likely to receive better support, and enjoy the most up to date bug fixes, security patches, etc., by using Y, not X. It doesn't matter if Y happens to have pre in it, i.e. 1.16.0.pre.1.

I get that regressions are hard for a project at this stage/size to control, but I don't see how this decision is really going to change anything. By moving end users to potentially unstable prereleases, you might improve the stability of the "official" releases, but it won't matter, because the "official" releases aren't what you're pushing your users to actually use.

This strikes me as violating the spirit of versioning policies while sticking to the letter. Is there no other way to stabilize the official releases?

ntl commented Sep 11, 2017

Not enough people install Bundler betas as is, and then people get angry when we release a stable version that has regressions. We can't guarantee a stable release will be stable unless a larger portion of the community helps us test the prereleases, and we certainly won't get more beta testers if they don't know there's a beta to test!

Once you tell end users to download and use a newer version via a warning, that version is now effectively an official release. That warning message supersedes any prerelease caveat you put into the version string. If another software provider told any one of us, "use version Y, not X," we would infer that we're likely to receive better support, and enjoy the most up to date bug fixes, security patches, etc., by using Y, not X. It doesn't matter if Y happens to have pre in it, i.e. 1.16.0.pre.1.

I get that regressions are hard for a project at this stage/size to control, but I don't see how this decision is really going to change anything. By moving end users to potentially unstable prereleases, you might improve the stability of the "official" releases, but it won't matter, because the "official" releases aren't what you're pushing your users to actually use.

This strikes me as violating the spirit of versioning policies while sticking to the letter. Is there no other way to stabilize the official releases?

@coderanger

This comment has been minimized.

Show comment
Hide comment
@coderanger

coderanger Sep 11, 2017

Contributor

I think y'all presume that FOSS project pre-releases are random snapshots. It's very rare that much changes between initial release candidates and final releases in smaller projects. This is mostly because any bugs the dev team can catch have already been squashed by then. So unless there's a lot of users exercising pre.1 it's probably literally the same as what will ship as .0 a few days later. So if you are worried that installing a pre.1 would destabilize your system, I've got some bad news for you ...

Contributor

coderanger commented Sep 11, 2017

I think y'all presume that FOSS project pre-releases are random snapshots. It's very rare that much changes between initial release candidates and final releases in smaller projects. This is mostly because any bugs the dev team can catch have already been squashed by then. So unless there's a lot of users exercising pre.1 it's probably literally the same as what will ship as .0 a few days later. So if you are worried that installing a pre.1 would destabilize your system, I've got some bad news for you ...

@ilude

This comment has been minimized.

Show comment
Hide comment
@ilude

ilude Sep 11, 2017

@coderanger I understand what you are saying but that is not the issue here. The issue is using a warning level message to display what is in fact a request by the devs to test out the latest version of bundler. That's not what warning messages are for! If 1.16 fixed a heartbleed level security issue or something similar I would not have issue with them using this method to alert everyone. Using a warning to post what is at best an info level request/suggestion is not the right way to do this.

I completely understand the intent of what they are doing, and I applaud them for making an attempt to deal with the issue of getting more beta testers for release candidates. I'm simply trying to express that this is not the proper way of doing it. And in the long run is going to lead to a whole lot of people disabling this messaging which will in fact make the problem they attempted to solve worse down the road.

ilude commented Sep 11, 2017

@coderanger I understand what you are saying but that is not the issue here. The issue is using a warning level message to display what is in fact a request by the devs to test out the latest version of bundler. That's not what warning messages are for! If 1.16 fixed a heartbleed level security issue or something similar I would not have issue with them using this method to alert everyone. Using a warning to post what is at best an info level request/suggestion is not the right way to do this.

I completely understand the intent of what they are doing, and I applaud them for making an attempt to deal with the issue of getting more beta testers for release candidates. I'm simply trying to express that this is not the proper way of doing it. And in the long run is going to lead to a whole lot of people disabling this messaging which will in fact make the problem they attempted to solve worse down the road.

@indirect

This comment has been minimized.

Show comment
Hide comment
@indirect

indirect Sep 11, 2017

Member

@mtgrosser You obviously still decide when to upgrade, and you can easily disable the message if you don't want to see it. Feel free to provide constructive feedback, or to stop using Bundler. Either way, stop shouting angrily at developers for not doing exactly what you personally want in a free tool or you will be moderated out of here.

@Odaeus @bobvanderlinden I think a separate flag to disable only prerelease warnings is reasonable; I have also already proposed disabling prerelease warnings on any "deployment mode" install.

@tomstuart Thanks for the feedback. We're trying to resolve the situation of "new minor releases end up with uncaught regressions". Without a notice for prereleases, the situation is exactly the same as the one you're describing, but for .0 releases: new users upgrade to 1.x.0, and experienced users know to avoid the .0 release because it might have uncaught bugs. We talked about adding an opt-in prerelease, but concluded that it would not result in a change to the status quo.

This is currently the best compromise we have come up with, and after we update the message as I described above, at least new users will know from the message that it is a prerelease and how to turn off the warning. If you have other ideas for how we could accomplish the same goal via other means you find more appealing, I'd love to hear about it.

@agorf @dgpokl As you may have noticed, we are already planning on doing that exact thing: expanding the warning message to explain more about prerelease versions.

@ilude We are already going to disable the prerelease warnings in deployment/production mode. You are also already able to resolve the warning by turning it off. We have not broken your production workflow, the devs you have trained are safe, and your sarcastic incredulity and shrillness are not acceptable behavior. Provide constructive feedback or go away. You won't be warned again.

@ntl Prereleases aren't beta versions, they are preview releases. We push them when a release is ready, and as you can see in the changelog, the final release is the exact same code (unless we find and fix regressions, and then the final is the same code as the subsequent preview). Given that we will not be showing this warning on deployment installs, and the entire point of these messages is to ensure that .0 releases are more stable than they are today, do you have any other suggestions?

Member

indirect commented Sep 11, 2017

@mtgrosser You obviously still decide when to upgrade, and you can easily disable the message if you don't want to see it. Feel free to provide constructive feedback, or to stop using Bundler. Either way, stop shouting angrily at developers for not doing exactly what you personally want in a free tool or you will be moderated out of here.

@Odaeus @bobvanderlinden I think a separate flag to disable only prerelease warnings is reasonable; I have also already proposed disabling prerelease warnings on any "deployment mode" install.

@tomstuart Thanks for the feedback. We're trying to resolve the situation of "new minor releases end up with uncaught regressions". Without a notice for prereleases, the situation is exactly the same as the one you're describing, but for .0 releases: new users upgrade to 1.x.0, and experienced users know to avoid the .0 release because it might have uncaught bugs. We talked about adding an opt-in prerelease, but concluded that it would not result in a change to the status quo.

This is currently the best compromise we have come up with, and after we update the message as I described above, at least new users will know from the message that it is a prerelease and how to turn off the warning. If you have other ideas for how we could accomplish the same goal via other means you find more appealing, I'd love to hear about it.

@agorf @dgpokl As you may have noticed, we are already planning on doing that exact thing: expanding the warning message to explain more about prerelease versions.

@ilude We are already going to disable the prerelease warnings in deployment/production mode. You are also already able to resolve the warning by turning it off. We have not broken your production workflow, the devs you have trained are safe, and your sarcastic incredulity and shrillness are not acceptable behavior. Provide constructive feedback or go away. You won't be warned again.

@ntl Prereleases aren't beta versions, they are preview releases. We push them when a release is ready, and as you can see in the changelog, the final release is the exact same code (unless we find and fix regressions, and then the final is the same code as the subsequent preview). Given that we will not be showing this warning on deployment installs, and the entire point of these messages is to ensure that .0 releases are more stable than they are today, do you have any other suggestions?

@ntl

This comment has been minimized.

Show comment
Hide comment
@ntl

ntl Sep 11, 2017

@indirect I see what you mean, and I now realize I had a much different impression of 1.16.0.pre.1 than y'all intended. My suggestions:

  • Reduce the severity of the message from warning to informational. So, regular text color, written to stdout, etc.
  • Indicate that there is a preview release for the next major version that, barring any regressions discovered by the end users, will be released as-is shortly. Do not simply instruct the user to upgrade, inform the user of their opportunity to upgrade.
  • Always show the message -- do not decide to hide it based on the --deployment flag. When your end users are releasing their own software, they might be caught off guard by a message that appeared on their development machines but not on their build machines (or production, if they're still doing git-over-ssh style deployments). Many operators don't pay attention to textual output during builds/releases, but the savvy/experienced ones do.
  • I recommend the terminology of "release candidate" over "prerelease." It connotes much greater confidence, and more specifically it inherently conveys that the version will likely be released as-is. It's also been around in open source software for a long time.
  • End users might be checking their Gemfile.lock into version control and including it in their build or release processes. I tend to discourage this practice, but those users might need additional messaging if their build/release process would end up issuing a warning that the bundler version for the project is supposed to be 1.16.0.pre.1. I'm not sure if this is even an issue; it's purely speculative on my part.

ntl commented Sep 11, 2017

@indirect I see what you mean, and I now realize I had a much different impression of 1.16.0.pre.1 than y'all intended. My suggestions:

  • Reduce the severity of the message from warning to informational. So, regular text color, written to stdout, etc.
  • Indicate that there is a preview release for the next major version that, barring any regressions discovered by the end users, will be released as-is shortly. Do not simply instruct the user to upgrade, inform the user of their opportunity to upgrade.
  • Always show the message -- do not decide to hide it based on the --deployment flag. When your end users are releasing their own software, they might be caught off guard by a message that appeared on their development machines but not on their build machines (or production, if they're still doing git-over-ssh style deployments). Many operators don't pay attention to textual output during builds/releases, but the savvy/experienced ones do.
  • I recommend the terminology of "release candidate" over "prerelease." It connotes much greater confidence, and more specifically it inherently conveys that the version will likely be released as-is. It's also been around in open source software for a long time.
  • End users might be checking their Gemfile.lock into version control and including it in their build or release processes. I tend to discourage this practice, but those users might need additional messaging if their build/release process would end up issuing a warning that the bundler version for the project is supposed to be 1.16.0.pre.1. I'm not sure if this is even an issue; it's purely speculative on my part.
@ilude

This comment has been minimized.

Show comment
Hide comment
@ilude

ilude Sep 11, 2017

@indirect my apologies, for the sarcasm and shrillness, it was not my intent. I truly do appreciated everything that each and every member of the team does! I will buy you all several drinks, should we ever meet, or send the team a paypal donation to show my appreciation (just tell me where). I was trying to make a point and be clear about the level of frustration this was causing on my end.

You've stated that you are going to make the change so that when --deployment is used the message is not displayed that's a solution that will work for me and I think many others but that's not what was being communicated in this thread.

If I may in closing say that this is a two way street and so when you ask for one side to be cordial and constructive it helps a lot when that same level of credence and respect is offered by the members of the bundler team to us the users.

ilude commented Sep 11, 2017

@indirect my apologies, for the sarcasm and shrillness, it was not my intent. I truly do appreciated everything that each and every member of the team does! I will buy you all several drinks, should we ever meet, or send the team a paypal donation to show my appreciation (just tell me where). I was trying to make a point and be clear about the level of frustration this was causing on my end.

You've stated that you are going to make the change so that when --deployment is used the message is not displayed that's a solution that will work for me and I think many others but that's not what was being communicated in this thread.

If I may in closing say that this is a two way street and so when you ask for one side to be cordial and constructive it helps a lot when that same level of credence and respect is offered by the members of the bundler team to us the users.

@indirect

This comment has been minimized.

Show comment
Hide comment
@indirect

indirect Sep 11, 2017

Member

@ntl @ilude thanks for the feedback! We'll keep it in mind when we update how the message works.

Member

indirect commented Sep 11, 2017

@ntl @ilude thanks for the feedback! We'll keep it in mind when we update how the message works.

@HoneyryderChuck

This comment has been minimized.

Show comment
Hide comment
@HoneyryderChuck

HoneyryderChuck Sep 11, 2017

this is very interesting, I always wondered who many opt-in to beta releases in a normal scenario, and how effective this release model is (I see rails doing it, and I don't know how many bugs have been prevented because of this).

I have experienced this pre-release warning message during last week and I found it weird (my first instinct was "if you HTTP Party, you gotta party hard!", but didn't bother me in the end that much. However I'd consider myself a "power user", and I've worked with people who use ruby for small-purpose scriptsm who shout and scream every time they have to deal with some environment tool like chruby or rubygems or bundler, and every yellow/red warning message is treated with "potential nuclear disaster" caution.

I do have one suggestion: why don't you enable this only for bundle update or bundle add? I found this weird for bundle install because I expect the outcome to be "predictable", meaning: whatever's in the lock file will be verified and eventually locally installed. And even the bundler version is nowadays declared in it. The same way that I don't get suggestions about newer versions from gems declared in the manifest, I don't expect them from bundler either.

But when I do bundle update or bundle add, I'm explicitly updating the state of the world, and this could be a good time to get this kind of suggestions. This might not broaden your testers pool as much as you'd like, but could work as a reasonable trade-off.

HoneyryderChuck commented Sep 11, 2017

this is very interesting, I always wondered who many opt-in to beta releases in a normal scenario, and how effective this release model is (I see rails doing it, and I don't know how many bugs have been prevented because of this).

I have experienced this pre-release warning message during last week and I found it weird (my first instinct was "if you HTTP Party, you gotta party hard!", but didn't bother me in the end that much. However I'd consider myself a "power user", and I've worked with people who use ruby for small-purpose scriptsm who shout and scream every time they have to deal with some environment tool like chruby or rubygems or bundler, and every yellow/red warning message is treated with "potential nuclear disaster" caution.

I do have one suggestion: why don't you enable this only for bundle update or bundle add? I found this weird for bundle install because I expect the outcome to be "predictable", meaning: whatever's in the lock file will be verified and eventually locally installed. And even the bundler version is nowadays declared in it. The same way that I don't get suggestions about newer versions from gems declared in the manifest, I don't expect them from bundler either.

But when I do bundle update or bundle add, I'm explicitly updating the state of the world, and this could be a good time to get this kind of suggestions. This might not broaden your testers pool as much as you'd like, but could work as a reasonable trade-off.

@jrochkind

This comment has been minimized.

Show comment
Hide comment
@jrochkind

jrochkind Sep 12, 2017

Contributor

I think y'all presume that FOSS project pre-releases are random snapshots. It's very rare that much changes between initial release candidates and final releases in smaller projects. This is mostly because any bugs the dev team can catch have already been squashed by then.

If you want all users to install it, then why not just release it as an actual non-pre release, and fix bugs in a patch release? After all, even .0 releases have bugs sometimes.

If the bundler team really does want all users to install the pre-release, believing it is suitable for production, that would be the appropriate behavior -- and nobody would be complaining anymore about the message. (They might be complaining about the stability of bundler releases, I dunno).

Contributor

jrochkind commented Sep 12, 2017

I think y'all presume that FOSS project pre-releases are random snapshots. It's very rare that much changes between initial release candidates and final releases in smaller projects. This is mostly because any bugs the dev team can catch have already been squashed by then.

If you want all users to install it, then why not just release it as an actual non-pre release, and fix bugs in a patch release? After all, even .0 releases have bugs sometimes.

If the bundler team really does want all users to install the pre-release, believing it is suitable for production, that would be the appropriate behavior -- and nobody would be complaining anymore about the message. (They might be complaining about the stability of bundler releases, I dunno).

@mtgrosser

This comment has been minimized.

Show comment
Hide comment
@mtgrosser

mtgrosser Sep 12, 2017

@indirect Bundler is becoming the systemd (or should I say Google?) of the Ruby world. You cannot (easily) get around using it, and it is forcefully imposing questionable design decisions on its users. This is what I am criticizing here. "With great power..."

When installing the bundle during the deployment of production applications, the bundler version is fixed by the current Ruby installation, which is not about to be changed in any way. Update reminders are out of place in this context, as is issuing any extra commands, editing config files, setting environment variables or command line switches in order to suppress them. And I'm not even talking about prereleases here. The same applies to the testing environment, as others set out above.

What if every gem developer adopted your way of reminding of updates, putting warnings on the console?

mtgrosser commented Sep 12, 2017

@indirect Bundler is becoming the systemd (or should I say Google?) of the Ruby world. You cannot (easily) get around using it, and it is forcefully imposing questionable design decisions on its users. This is what I am criticizing here. "With great power..."

When installing the bundle during the deployment of production applications, the bundler version is fixed by the current Ruby installation, which is not about to be changed in any way. Update reminders are out of place in this context, as is issuing any extra commands, editing config files, setting environment variables or command line switches in order to suppress them. And I'm not even talking about prereleases here. The same applies to the testing environment, as others set out above.

What if every gem developer adopted your way of reminding of updates, putting warnings on the console?

@indirect

This comment has been minimized.

Show comment
Hide comment
@indirect

indirect Sep 12, 2017

Member

@HoneyryderChuck thanks for the feedback!

@jrochkind The goal is to get some usage in development environments via preview releases prior to pushing a .0 for production environments. Hopefully we can catch and fix those bugs before the final release and full adoption.

@mtgrosser Angrily comparing Bundler to systemd or Google instead of giving specific and constructive feedback is a perfect example of the kind of thing I already warned you against. Goodbye.

Member

indirect commented Sep 12, 2017

@HoneyryderChuck thanks for the feedback!

@jrochkind The goal is to get some usage in development environments via preview releases prior to pushing a .0 for production environments. Hopefully we can catch and fix those bugs before the final release and full adoption.

@mtgrosser Angrily comparing Bundler to systemd or Google instead of giving specific and constructive feedback is a perfect example of the kind of thing I already warned you against. Goodbye.

@mchilson

This comment has been minimized.

Show comment
Hide comment
@mchilson

mchilson Sep 12, 2017

Hi Andre' ,

First, thank you for all yours and the bundler team's work. I greatly appreciate the effort! An idea... What about just adding an additional config option to disable pre-release notices specifically? Since you already have "bundle config disable_update_message true" what about something like "bundle config disable_prerelease_message true"? This would give users an option to turn the notice off but still get notices of full releases?

By the way, I would be happy to volunteer my resources and time to help your guys communicate with users better. FB & Twitter, a signup mailing list. Just let me know.

Many thanks!
Mike

mchilson commented Sep 12, 2017

Hi Andre' ,

First, thank you for all yours and the bundler team's work. I greatly appreciate the effort! An idea... What about just adding an additional config option to disable pre-release notices specifically? Since you already have "bundle config disable_update_message true" what about something like "bundle config disable_prerelease_message true"? This would give users an option to turn the notice off but still get notices of full releases?

By the way, I would be happy to volunteer my resources and time to help your guys communicate with users better. FB & Twitter, a signup mailing list. Just let me know.

Many thanks!
Mike

@dgpokl

This comment has been minimized.

Show comment
Hide comment
@dgpokl

dgpokl Sep 12, 2017

Happy to see at least the ability to suppress this message in deployment mode; however, the way we use Bundler is that bundler is used in development mode; it writes the Gemfile.lock, and that file is used in production. So the bundler that I run on my laptop is part of the production toolchain. I wouldn't feel comfortable with anyone on my team running the beta or "preview." when modifying the Gemfile.lock for production use. Since just choosing to run with --deployment on my dev machine has other unwanted side effects such as installing to the vendor bundle, I wonder if there's still room to lobby for the ability to turn this off for non-release versions across the board.

I'd point to things like Chrome which allow you to pick a channel. People who are comfortable and prefer running the latest version can join a more aggressive release channel; people who need to be conservative can use the stable release channel. By offering just one option (heck, you can default it to "pre-release-inclusive" when in non-deployment mode for all I care – I wouldn't like it but I see that you really want to increase adoption of non-stable builds) you could let people simply choose which kind of new version they'll get warnings about.

dgpokl commented Sep 12, 2017

Happy to see at least the ability to suppress this message in deployment mode; however, the way we use Bundler is that bundler is used in development mode; it writes the Gemfile.lock, and that file is used in production. So the bundler that I run on my laptop is part of the production toolchain. I wouldn't feel comfortable with anyone on my team running the beta or "preview." when modifying the Gemfile.lock for production use. Since just choosing to run with --deployment on my dev machine has other unwanted side effects such as installing to the vendor bundle, I wonder if there's still room to lobby for the ability to turn this off for non-release versions across the board.

I'd point to things like Chrome which allow you to pick a channel. People who are comfortable and prefer running the latest version can join a more aggressive release channel; people who need to be conservative can use the stable release channel. By offering just one option (heck, you can default it to "pre-release-inclusive" when in non-deployment mode for all I care – I wouldn't like it but I see that you really want to increase adoption of non-stable builds) you could let people simply choose which kind of new version they'll get warnings about.

@iHiD

This comment has been minimized.

Show comment
Hide comment
@iHiD

iHiD Sep 12, 2017

Cutting through all the discussion about hiding the warning, I've never known that Bundler pre-releases were a thing and never tried them. Now I know that I can, I will. So 👍 for telling me how to help :)

The expanded language that's been suggested would also definitely encourage me more. It would be especially important to me to know where to report bugs, and how to roll-back if I hit issues. A link to the release notes would be a nice-to-have but less important for me. You've already indicated you're going to address that language, but I wanted to give an explicit 👍 to it.

Thanks for all your work on Bundler. I remember a time without it, and its introduction was a true step-change for Ruby. Without it now, the whole ecosystem would collapse, so your generosity in giving your time to it is vastly appreciated.

iHiD commented Sep 12, 2017

Cutting through all the discussion about hiding the warning, I've never known that Bundler pre-releases were a thing and never tried them. Now I know that I can, I will. So 👍 for telling me how to help :)

The expanded language that's been suggested would also definitely encourage me more. It would be especially important to me to know where to report bugs, and how to roll-back if I hit issues. A link to the release notes would be a nice-to-have but less important for me. You've already indicated you're going to address that language, but I wanted to give an explicit 👍 to it.

Thanks for all your work on Bundler. I remember a time without it, and its introduction was a true step-change for Ruby. Without it now, the whole ecosystem would collapse, so your generosity in giving your time to it is vastly appreciated.

@radar

This comment has been minimized.

Show comment
Hide comment
@radar

radar Sep 12, 2017

Contributor

@ilude

I truly do appreciated everything that each and every member of the team does! I will buy you all several drinks, should we ever meet, or send the team a paypal donation to show my appreciation (just tell me where)

You could set up a monthly donation here: https://rubytogether.org/

Contributor

radar commented Sep 12, 2017

@ilude

I truly do appreciated everything that each and every member of the team does! I will buy you all several drinks, should we ever meet, or send the team a paypal donation to show my appreciation (just tell me where)

You could set up a monthly donation here: https://rubytogether.org/

@lamont-granquist

This comment has been minimized.

Show comment
Hide comment
@lamont-granquist

lamont-granquist Sep 13, 2017

Contributor

FWIW, this message worked perfectly for me, and did the job the devs intended it to do.

I'm busy and don't have time to track the bundler project day-to-day. I'm also a person who should be installing bundler pre release and determining if some of our horrible abuses of bundler at work have broken, so I should be installing pre releases. The warning message alerted me to the fact that a prerelease had been issued and I installed it in order to test it. If the warning wasn't there, I wouldn't have done that.

And since testing bundler, while important, is not my primary job, I won't be reorganizing my life to stay constantly up-to-date on bundler prereleases (generally I've done lots of work to rip out abuses of bundler in our environment so that I can think less and less about bundler in the future and that's the trend I'd like to see continue). The message, however, worked perfectly to fit it into my workflow.

We also have issues in our project with getting users to test prereleases, and shipping releases that occasionally turn up fairly obvious bugs because nobody tests the prereleases because everyone in the world is perpetually busy.

Contributor

lamont-granquist commented Sep 13, 2017

FWIW, this message worked perfectly for me, and did the job the devs intended it to do.

I'm busy and don't have time to track the bundler project day-to-day. I'm also a person who should be installing bundler pre release and determining if some of our horrible abuses of bundler at work have broken, so I should be installing pre releases. The warning message alerted me to the fact that a prerelease had been issued and I installed it in order to test it. If the warning wasn't there, I wouldn't have done that.

And since testing bundler, while important, is not my primary job, I won't be reorganizing my life to stay constantly up-to-date on bundler prereleases (generally I've done lots of work to rip out abuses of bundler in our environment so that I can think less and less about bundler in the future and that's the trend I'd like to see continue). The message, however, worked perfectly to fit it into my workflow.

We also have issues in our project with getting users to test prereleases, and shipping releases that occasionally turn up fairly obvious bugs because nobody tests the prereleases because everyone in the world is perpetually busy.

@wpostma

This comment has been minimized.

Show comment
Hide comment
@wpostma

wpostma Sep 13, 2017

I'm a relatively new and inexperienced Ruby user and this change seems user hostile to me. If the wording was changed to "Please consider helping us test this pre-release", instead of "you are running version x but a newer version y is available", implying I should upgrade now, then it would not seem user hostile.

wpostma commented Sep 13, 2017

I'm a relatively new and inexperienced Ruby user and this change seems user hostile to me. If the wording was changed to "Please consider helping us test this pre-release", instead of "you are running version x but a newer version y is available", implying I should upgrade now, then it would not seem user hostile.

@dgpokl

This comment has been minimized.

Show comment
Hide comment
@dgpokl

dgpokl Sep 13, 2017

@wpostma @tachyons The bundler maintainer @indirect has stated a pretty clear intention to fix the message; I plan to give them some time to implement this. Also, let's all install the next pre-release to find out as soon as possible if our issue has been resolved 😉

dgpokl commented Sep 13, 2017

@wpostma @tachyons The bundler maintainer @indirect has stated a pretty clear intention to fix the message; I plan to give them some time to implement this. Also, let's all install the next pre-release to find out as soon as possible if our issue has been resolved 😉

@deXterbed

This comment has been minimized.

Show comment
Hide comment
@deXterbed

deXterbed Sep 13, 2017

so much fuss over a warning?

deXterbed commented Sep 13, 2017

so much fuss over a warning?

@segiddins

This comment has been minimized.

Show comment
Hide comment
@segiddins

segiddins Sep 13, 2017

Member

#6031 we're disabling the warning by default for now, until the feedback from this issue can be taken into account to (a) update the message and (b) narrow down the context under which the message is shown in the first place.

Hopefully, this will give us all time to make a PR and come to a consensus as to what is most useful for the community at large, and so y'all can chime in on any proposed changes.

Member

segiddins commented Sep 13, 2017

#6031 we're disabling the warning by default for now, until the feedback from this issue can be taken into account to (a) update the message and (b) narrow down the context under which the message is shown in the first place.

Hopefully, this will give us all time to make a PR and come to a consensus as to what is most useful for the community at large, and so y'all can chime in on any proposed changes.

bundlerbot added a commit that referenced this issue Sep 14, 2017

Auto merge of #6031 - bundler:seg-disable-new-version-warning-by-defa…
…ult, r=indirect

[CLI] For now, disable the new version warning by default

### What was the end-user problem that led to this PR?

The problem was people were getting confused by the terseness and bluntness of the current outdated bundler version warning.

### What was your diagnosis of the problem?

My diagnosis was we need to spend time fine-tuning the message, including when it is displayed. But given the lack of time to do so immediately, I thought it best to disable the warning for now, until someone can make a PR that addresses the comments and concerns raised in #6004.

segiddins added a commit that referenced this issue Sep 18, 2017

Auto merge of #6031 - bundler:seg-disable-new-version-warning-by-defa…
…ult, r=indirect

[CLI] For now, disable the new version warning by default

### What was the end-user problem that led to this PR?

The problem was people were getting confused by the terseness and bluntness of the current outdated bundler version warning.

### What was your diagnosis of the problem?

My diagnosis was we need to spend time fine-tuning the message, including when it is displayed. But given the lack of time to do so immediately, I thought it best to disable the warning for now, until someone can make a PR that addresses the comments and concerns raised in #6004.

(cherry picked from commit 8609a06)
@tachyons

This comment has been minimized.

Show comment
Hide comment
@tachyons

tachyons Sep 28, 2017

Any ETA for releasing this fix, I am still getting this odd message,
Thanks

tachyons commented Sep 28, 2017

Any ETA for releasing this fix, I am still getting this odd message,
Thanks

@arbonap

This comment has been minimized.

Show comment
Hide comment
@arbonap

arbonap Sep 28, 2017

Contributor

Hi @tachyons, a PR has been merged disabling this warning by default. You can see the commit here. Feel free to bundle config disable_version_check true to ignore the message for now.

Contributor

arbonap commented Sep 28, 2017

Hi @tachyons, a PR has been merged disabling this warning by default. You can see the commit here. Feel free to bundle config disable_version_check true to ignore the message for now.

@caseyprovost

This comment has been minimized.

Show comment
Hide comment
@caseyprovost

caseyprovost Oct 23, 2017

There should be a way to segment warnings per type of build to some degree if this is the goal. Maybe have a .bundler file or similar with settings such as below:

--ignore-pre-release-warnings=false
--ignore-beta-release-warnings=false

It would be conducive to future settings configurations that would be useful based on a variety of needs.

caseyprovost commented Oct 23, 2017

There should be a way to segment warnings per type of build to some degree if this is the goal. Maybe have a .bundler file or similar with settings such as below:

--ignore-pre-release-warnings=false
--ignore-beta-release-warnings=false

It would be conducive to future settings configurations that would be useful based on a variety of needs.

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