Hi I want to pin a particular version of dependency in my go.mod, like
github.com/dependecy v1.7.0
And when I run go test or go build, sometimes it gets updated to
github.com/dependecy v1.8.0
The tricky part is sometimes it changes, and sometimes it does not. We would want to pin to an older version because the new version has a bug. Any idea why this is happening?
I believe the reason why this is happening is because you might have a dependency that might have requirement for higher version of the module. From go documentation here
If multiple versions of a particular module are added to the list, then at the end only the latest version (according to semantic version ordering) is kept for use in the build.
You can try the commands listed in documentation or, run go build with -mod=readonly flag. That should help you understand what might be triggering this.
Go modules does not support multiple minor versions of same package in a single module, if added then at the end only the latest version is kept for use in the build.
You can have some dependency which have requirement of higher version and replacing the old one.
If a module out there pushed v1.8.0 with a bug, file a bug or fork the repository as needed.
Related
If I run lein install the terminal throws an error:
➜ lein install
If there are a lot of uncached dependencies this might take a while ...
Release versions may not depend upon snapshots.
Freeze snapshots to dated versions or set the LEIN_SNAPSHOTS_IN_RELEASE environment variable to override.
But, if I do what the (obscure) error message suggests and if I prefix
the command with LEIN_SNAPSHOTS_IN_RELEASE=true, it succeeds:
➜ LEIN_SNAPSHOTS_IN_RELEASE=true lein install
If there are a lot of uncached dependencies this might take a while ...
Created /Users/pedro/projects/my-project-name/target/1.3.0-ONE-PROJECT-REPOSITORY-NAME.jar
Wrote /Users/pedro/projects/my-project-name/pom.xml
Installed jar and pom into local repo.
I would like to understand this better.
Why is the prefix needed? Why can't Lein just accept lein install?
What is the reason/context behind this design?
Obs.: on project.clj the project name does not include the word SNAPSHOT. I have:
(defproject my-project-name "1.3.0-ONE-PROJECT-REPOSITORY-NAME" ...
I suspect one of your dependencies are pointing to a SNAPSHOT version?
I guess Leiningen does not allow you to release a "stable" (non-SNAPSHOT) version of anything that depends on something non-stable itself. Imagine your library depending on function xyz in the library [abc "1.0.0-SNAPSHOT"]. But in the snapshot version of abc released tomorrow the function xyz have been refactored, so the function signature is different, or maybe xyz has been removed altogether. Now your stable library doesn't work anymore.
That is why Leining wants it to be a deliberate decision (that takes extra effort) to do such things. But without knowing the exact version of Leiningen and the full dependency tree, I cannot say for sure, nor reproduce the behavior locally.
Also see the Leiningen documentation:
Snapshot Versions
Sometimes versions will end in "-SNAPSHOT". This means that it is not an official release but a development build. Relying on snapshot dependencies is discouraged but is sometimes necessary if you need bug fixes, etc. that have not made their way into a release yet. However, snapshot versions are not guaranteed to stick around, so it's important that non-development releases never depend upon snapshot versions that you don't control. Adding a snapshot dependency to your project will cause Leiningen to actively go seek out the latest version of the dependency daily (whereas normal release versions are cached in the local repository) so if you have a lot of snapshots it will slow things down.
Note that some libraries make their group-id and artifact-id correspond with the namespace they provide inside the jar, but this is just a convention. There is no guarantee they will match up at all, so consult the library's documentation before writing your :require and :import clauses.
I am in the process of modularising my app using Swift Packages and some of these modules will be useful for future apps so I have created standalone Packages and added them to the main project as dependencies.
As recommended, I am using semantic versioning and have tagged the commit as per the Apple documentation (see here) and pushed to my Github account.
When I attempt to add this package to my app using version rules ("up to next major version") the dependency does not seem to be resolved properly; the code cached locally only contains a bare package without any of the code I subsequently added.
If I remove version rules and use commit rules instead, I get the whole package as expected but that may cause problems with compatibility in the future as the package evolves.
Checking the version control in Xcode and directly on Github shows that the version tag 1.0.0 is present and associated with the last commit which is puzzling. The steps taken in an attempt to resolve the issue are as follows:
force push package (including tag) to GitHub
remove version control from package by deleting .git file and adding version control, committing, tagging then pushing to remote
reset package caches
clear derived data
close and restart XCode
None of the above work and I thought initially that I was not doing things in the correct order. However I'm particularly puzzled that removing version control then setting it back up again (with the code codebase in a complete state at this time) didn't work as the bare-bones template package was never pushed to the remote in the first place. I don't understand how can Xcode be still retrieving it. IMO this suggests there's a cache somewhere it's falling back to (despite being told to clear the cache) but I stand to be corrected.
Screenshots of the remote (showing the correct tag) and states of the Xcode package dependency using branch rules and version rules attached.
Today I upgraded to Go 1.17. The release notes at https://golang.org/doc/go1.17 talk about this new feature:
Module authors may deprecate a module by adding a // Deprecated: comment to go.mod
I know from Go 1.16 that go.mod file can specify a retract directive and retract a module version, or more versions.
The usage of the new // Deprecated comment is similar to retract. Please can you formally explain when I should use // Deprecate and when retract?
You should use // Deprecated: comment to indicate you don't support a major version anymore. For example you released v2.0.0, and you don't intend to work on v1.0.0 anymore. v1.0.0 may still work as intended, but it may lack many new features you only intend to add to v2.0.0.
retract can be used to mark a minor or patch version (or a range of versions enclosed in [ ]) that may contain a severe bug or vulnerability and they should not be used. For example you may release v1.2.0 and 2 days later someone discovers a security vulnerability in it. You may modify go.mod to add retract to version v1.2.0, and mark this addition as v1.2.1:
retract (
v1.2.0 // Security vulnerability discovered.
v1.2.1 // Contains retractions only.
[v3.0.0, v3.9.9] // Retract all from v3
)
This will inform the go tool not to upgrade to v1.2.0 nor to v1.2.1 (e.g. when you instruct to update to the latest version with go get example.com/m#latest). When you fixed the issue and release v1.2.2, go get example.com/m#latest will update to v1.2.2.
Quoting from Go Modules Reference: Deprecation:
Deprecation messages are intended to inform users that the module is no longer supported and to provide migration instructions, for example, to the latest major version. Individual minor and patch versions cannot be deprecated; retract may be more appropriate for that.
And quoting from retract directive:
A retract directive indicates that a version or range of versions of the module defined by go.mod should not be depended upon. A retract directive is useful when a version was published prematurely or a severe problem was discovered after the version was published. Retracted versions should remain available in version control repositories and on module proxies to ensure that builds that depend on them are not broken.
I'm new in Golang, and I'm trying to develop a go-module and share it with my colleagues while I'm developing it; In JVM/sbt I used to publish my work with a 'SNAPSHOT' postfixed to version value. but How I can achieve the same in with go-modules?
Versions for modules are tagged by using repo tags (e.g. git tag), following semantic versioning (https://semver.org/).
So, any version starting with v0 is treated as unstable and may make breaking changes at any time. Once you release a v1, you cannot make any breaking changes without bumping your major version, which also means you change your module name.
You also have the option of appending +foo to the end of your version to indicate additional information about the version.
I wrote https://blog.golang.org/using-go-modules as an overview of how to get started using modules.
Is it ok to use the master branch of lib/pq in production?
When you execute go get gitlab.com/lib/pq you get the master branch, but there is a release v1.0.0.
Would it be better to use releases instead of master branch?
lib/pq
Releases
v1.0.0
Initial tagged release. No major recent changes.
Merge pull request #778 from lib/go-mod
add a go.mod file in preparation for a tagged release
lib/pq v1.0.0 adds support for Go versioned modules.
For Go1.12, consider upgrading your production code for Go versioned modules.
The first beta release of Go 1.12 is scheduled for this week (Dec, 3, 2018).
Go 1.11 Release Notes
Modules, package versioning, and dependency management
Go 1.11 adds preliminary support for a new concept called “modules,”
an alternative to GOPATH with integrated support for versioning and
package distribution. Using modules, developers are no longer confined
to working inside GOPATH, version dependency information is explicit
yet lightweight, and builds are more reliable and reproducible.
Module support is considered experimental. Details are likely to
change in response to feedback from Go 1.11 users, and we have more
tools planned. Although the details of module support may change,
projects that convert to modules using Go 1.11 will continue to work
with Go 1.12 and later. If you encounter bugs using modules, please
file issues so we can fix them. For more information, see the go
command documentation.
Proposal: Versioned Go Modules
Go 1.11 Modules.