Conversation
pensivebrian
left a comment
pensivebrian
left a comment
There was a problem hiding this comment.
Stable bits should never point to our storage account - we should link to the official repo.
Anytime we have to update a version, we should think about making a change to .bumpversion.cfg so that it's done automatically. There are probably a few place in our docs we should do this.
Unfortunately with regards to PyPI, there's a unique link that's generated for each wheel that's upload. You can see this here. What do you think is the best way to manage direct links to wheels? |
|
|
||
| [rpm]: https://mssqlcli.blob.core.windows.net/daily/rpm/mssql-cli-0.18.1-1.el8.x86_64.rpm | ||
|
|
||
| [whl-win-x64]: https://mssqlcli.blob.core.windows.net/daily/whl/mssql-cli/mssql_cli-0.18.1-py2.py3-none-win_amd64.whl |
There was a problem hiding this comment.
We shouldn't be pointing people at our blob storage account. Can you update these to point them to pypi? We should see if there is a way to gen the link as part of the version bump, though it becomes more complicated due to the hash.
There was a problem hiding this comment.
See my above comment on PyPI. Not sure what to do there. I'll get to RPM and DEB, however.
| [whl-win-x86]: https://files.pythonhosted.org/packages/21/8c/9829c2094b4f179f9c2f4548b2ba089867f84a3758cb70575ef2a905e877/mssql_cli-0.15.0-py2.py3-none-win32.whl | ||
| [whl-macos]: https://files.pythonhosted.org/packages/43/5d/c9af6aec5b491e7b0c5ccf00b4b8062282d6c4cfb4c0417891bd6013e299/mssql_cli-0.15.0-py2.py3-none-macosx_10_11_intel.whl | ||
|
|
||
| [deb]: https://mssqlcli.blob.core.windows.net/daily/deb/mssql-cli_0.18.1-1_all.deb |
There was a problem hiding this comment.
Same deal for the .deb and .rpm packages - they should point to packages.microsoft.com.
pensivebrian
left a comment
pensivebrian
left a comment
There was a problem hiding this comment.
Need to point links to pypi and packages.microsoft.com.
Here's a thought. What if we just removed all direct links? I just don't see the need to provide this, and also given my comments above on not being able to provide direct links to PyPI. |
ellbosch
force-pushed
the
ellbosch/update-stable-links
branch
from
0d53fe9 to
81e8c20
Compare
| [whl-win-x86]: https://files.pythonhosted.org/packages/21/8c/9829c2094b4f179f9c2f4548b2ba089867f84a3758cb70575ef2a905e877/mssql_cli-0.15.0-py2.py3-none-win32.whl | ||
| [whl-macos]: https://files.pythonhosted.org/packages/43/5d/c9af6aec5b491e7b0c5ccf00b4b8062282d6c4cfb4c0417891bd6013e299/mssql_cli-0.15.0-py2.py3-none-macosx_10_11_intel.whl | ||
|
|
||
| [deb]: https://packages.microsoft.com/ubuntu/16.04/prod/pool/main/m/mssql-cli/mssql-cli_1.0.0-1_all.deb |
There was a problem hiding this comment.
One issue is these files don't exist yet until we publish, so when we merge the vbump into master, the links won't work. I'm leaning towards just hand editing the links after we push to pypi and the other repos.
|
Holding off on this until 1.0 is released. |
ellbosch
force-pushed
the
ellbosch/update-stable-links
branch
from
b788ff7 to
4f5c198
Compare
ellbosch
force-pushed
the
ellbosch/update-stable-links
branch
from
4f5c198 to
efa4e01
Compare
|
@pensivebrian: my most recent commits update the Linux docs:
|
pensivebrian
left a comment
pensivebrian
left a comment
There was a problem hiding this comment.
This PR has now become two things: updating links and refactoring the install. Can we keep this focused on the install links?
For the install steps, we have the same steps for the other SQL Linux tools which have had a fair amount of testing. I'd like to keep them the same unless there is good reason to diverge.
I had chosen to go off the docs for Packages.Microsoft, but I can change if you prefer SQL Server docs. RPM instructions appear to be the only difference. SQL Server docs are missing a step to import the key, without which leads to signature warning, so I'll make sure to keep that. |
2 participants
I've updated links to point at latest stable version number, rather than use 'dev-latest'.
Furthermore, all downloads now point to our daily storage. @pensivebrian please let me know if this is good practice.