4 ms·
[EDIT] Will leave the questions up have delved deeper into this myself and the above questions I have are basically answered but I am surprised at the route tak
by rurounijones 8y ago
[EDIT] Will leave the questions up have delved deeper into this myself and the above questions I have are basically answered but I am surprised at the route taken. Seems like everyone should be including the major version in their import path from the very beginning and every subsequence version which seems... ehhhhh.
------------------
Not a Go dev:
Is the mantra of "the new package must be backwards compatible with the old package.", which is an underlying requirement for vgo to work, actually followed in the Go ecosystem? It seems crazy to me that a package would have to change its name if it wants to introduce a backwards incompatible change.
Has this happened in practice? How does it work? Are people going to suffix packages with "Really major major" version numbers separately from the actual version number?
The criticisms of bundler in the proposal seem to be be a bit wierd when the solution is to force a new paradigm on developers to make vgo's job easier.
Why even use Semantic versioning at that point since a major version can never be incremented.
- sacado2 8y agoIn all big packages I use: yes, it is. This is actually a must given there was no (standard) version management system. If you have no versioning system and don't make your code backwards compatible, you break someone else's code. So, either you make a new repository, or you make a subpackage in your current repository with the new, breaking version.
- pjmlp 8y agoI the context of versions I think Rickey puts it best, actually there are no guarantees of compatibility. Even a minor update can eventually break someone's code that relied on the bug. "Spec-ulation – Rich Hickey" https://www.youtube.com/watch?v=oyLBGkS5ICk https://www.youtube.com/watch?v=oyLBGkS5ICk