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

fix(MongoBinaryDownloadUrl): removed ssl from options #57

Merged
merged 1 commit into from
Mar 29, 2018

Conversation

YozhikM
Copy link
Contributor

@YozhikM YozhikM commented Mar 28, 2018

Referenced to this issue
Now binaries for OSX older than 3.0 version is immediately installed with the SSL. Before and including 3.0 - without.

Since the SSL is not used anywhere else, it is completely removed from the code

Now binaries older than 3.0 version are immediately installed with the
ssl. Before and including 3.0 - without.
@nodkz nodkz merged commit 64a435b into nodkz:master Mar 29, 2018
@nodkz
Copy link
Owner

nodkz commented Mar 29, 2018

Thanks! 👌👍

PS. Crazy man! When do you sleep?!

@nodkz
Copy link
Owner

nodkz commented Mar 29, 2018

🎉 This PR is included in version 1.7.3 🎉

The release is available on:

Your semantic-release bot 📦🚀

@YozhikM
Copy link
Contributor Author

YozhikM commented Mar 29, 2018

@nodkz While you're asleep, your enemy increases the level

@mathieug
Copy link
Contributor

mathieug commented Apr 17, 2018

Before implementing the ssl option, I started to check the mongodb version like this PR. I think it's better to let the developer to choose.
Maybe you could automatically set the default value but let the user overwrite it.

@nodkz
Copy link
Owner

nodkz commented Apr 20, 2018

@mathieug for information, all available links of MongoDB binaries:
Osx https://www.mongodb.org/dl/osx
Linux https://www.mongodb.org/dl/linux
Win https://www.mongodb.org/dl/win32

ssl option worked only with OSX and if you check available versions of binaries you may see that only several version between 3.0 and 3.4 have both ssl and no ssl binaries. So this option brings more mess than helps.

Can you provide use-case where ssl or no-ssl version is important?

@mathieug
Copy link
Contributor

mathieug commented Apr 20, 2018

I know, I have added the ssl option to this package.

I think some users could want to specify ssl or no-ssl with a specific version (between 3.0 and 3.4) and I didn't want to prevent them.
For my use, I don't care I always use the latest version.

@nodkz
Copy link
Owner

nodkz commented Apr 20, 2018

For my use, I don't care I always use the latest version.

Really, for testing purposes (the main aim of this package) it's no matter what type ssl or not-ssl version of binary have been started. It just should work. We had met with the various type of binary URL problems in #55 #51 and maybe several other issues. So the most comfortable and easy way to fix all problems was reducing the logic of determining correct download url. And this decision affected that we deleted ssl option.

I think that YAGNI principle is exactly this case ;)

@mathieug
Copy link
Contributor

I agree since I use the latest version which is only ssl. I just thought it could be this new behaviour by default with still an option to force it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants