Version management

[lminuti]

I noticed that in a project it's possible to insert a version.txt file to specify the version, but I didn't understand how to install a specific version of that project.

In my case, things would be even more complex because I'm trying to create the installation for a project (WiRL) that has several dependencies (neon, jwt, etc.). I would like to "lock" the dependencies to a specific version and I didn't understand if this is possible with the current version of SmartSetup.

Thanks.

[agallero]

Hi,
Versioning is not yet implemented, that is next in our todo list. At the moment, we only get the update to the latest version in the repo.
At this moment:

• Version.txt is used to show the version you are getting. It is more used in tms components, which go through a different server from github. But if you add it, it can show in tms list or tms gui (this is not 100% decided yet: we estimate that most github components won't have a version.txt, or if they have it, it won't be updated, so I believe we are ignoring it for now. But adding a version.txt to your repo won't hurt in any case).

The idea for the future is to use git tags to allow for versioning. So for example we can get https://github.com/delphi-blocks/WiRL/tree/v4.5.0 to download v4.5. This is on the pipeline and shouldn't be complex, but not right now as we also have to maintain our own components 🙂 As soon as time allows, it will be added.

About locking dependencies of a library, this hasn't been discussed yet, so what I say here is my personal opinion and not the one from the team, but I am not so sure it will be implemented. The idea is to allow the user locking his dependencies (the planned commands are tms pin and tms unpin) but I would like the user to be in control of what he pins, not third party libraries. The idea of use is that a user installs everything latest the first time, then he pins that config if he wants, then he can update everything to the latest again. If a library doesn't support the latest it should be updated (and not have all the other libraries use that older version because it isn't updated).

But well, as said this hasn't been done and we welcome all discussion on how you would like to do it. One thing I believe is certain is that we don't want a complex versioning system with semantic versioning and minimum and maximum versions allowed because in my experience that never works well (mostly because the component creators never keep the minimum and maximum dependencies up to date, and because semantic version can't be trusted)

[lminuti]

I like the idea of using git tags for versioning.

As for dependency management, while it's true that users have the final say, it should be possible to declare which versions of a dependency the library is compatible with. Other tools use syntax like ^4.18.0 to specify any 4.x.x >= 4.18.0, or ~4.17.20 to specify any 4.17.x >= 4.17.20. This provides a good degree of flexibility.