> On 6 May 2020, at 11.11, Reyhan Sofian Haqqi <computecoho...@gmail.com> wrote:
>
> Hi,
>
> I have a case where we developing inside a monorepo project where we
> distribute shared libs locally (without publishing) and we're using replace
> directive inside go.mod. What we fear is someone changes the shared libs
> logic, it might break other applications that use it because we can't have
> any version inside the shared libs module and the applications didn't aware
> of any changes inside the shared libs module. Is there any way to add
> versioning for this shared libs module? Is it work using pseudo-version?
You can use the usual semver on shared libs, and yes it should work with
pseudo-version too, as long as you use VCS to publish the changes,
The question is why you can't have any version inside the shared libs? How do
you shared the libs locally?
>
> For example, we have a module with pseudo-version
> v0.0.0-00010101000000-55b989e89570. And then Application A requires this
> module. If someone changes the shared libs logic and the pseudo-version
> changed to v0.0.0-00010101000000-c00dbbc9dadf. What will happen to
> Application A which uses module with pseudo-version
> v0.0.0-00010101000000-55b989e89570? Is it using the code from first
> pseudo-version or is it always using the latest code regardless of the
> pseudo-version?
>
If the replace directive use local path then I am afraid it will use the latest
pseudo version.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/FA321147-F40E-4F18-AD5F-CB1B2A687A3B%40gmail.com.
