froze pip package versions, upgraded pip, pointed to ubuntu 17 #4
Conversation
WanderingStar
left a comment
WanderingStar
left a comment
There was a problem hiding this comment.
What's the goal of making this fully stable on this particular set of dependencies? Is there a particular project that wants this stability? Will this be updated on a regular basis as the most stable versions come out?
| @@ -1,9 +1,10 @@ | |||
| FROM ubuntu | |||
| FROM ubuntu:17.10 | |||
There was a problem hiding this comment.
Why 17.10 and not 18.04? 18.04 is an LTS release, while 17.10 is not.
There was a problem hiding this comment.
18.04 was just released last week and I would want to fully test it. I didn't realize 17.10 was not lts.
|
Also, are you using —no-cache when you run build? I’m curious why you’re seeing full updates. |
|
if someone new picks this up and builds they will get the latest/greatest which may introduce new behaviors/bugs into the project. If a new version of library comes out and someone wants to upgrade to said library, it would up to them to test and update the new version. |
|
The idea behind this scaffolding repo is that it's a starting point, not a finished project. So it doesn't have functionality that needs to be maintained on a stable platform. You're right that someone using this will probably want stability once their project is under way. For example, a year from now, someone could use this project as a starting point. At that time, maybe Flask will be up to version 1.1, and will have some important bug fixes. They'd want to get their project working with the latest versions (not the versions that are current right now), and then freeze the requirements so that they would continue to have a stable platform. Perhaps the best way to approach that would be to add to the documentation to explain how to do what you've done with this commit when they are ready for that stability. Would you be interested in adding to the Readme to describe how someone could make this kind of change in their own project, when they reach the point that they're ready to? Sticking with a stable (ideally LTS) version of the OS and freezing the requirements is a good idea that the current Readme doesn't address at all. |
|
I can something to the readme about version numbers in the requirements and putting in tags to docker images. |
2 participants
Update should make this close to being fully stable instead of every time docker-compose build is run the latest/greatest will be installed.