Le 2019-04-02 15:11, Robert-André Mauchin a écrit :
On Tuesday, 2 April 2019 13:27:09 CEST Nicolas Mailhot wrote:
> Le 2019-04-02 12:52, Jakub Cajka a écrit :
>
>
> > I might have not been clear, sorry. My point is more that we don't
> > need to recreate/capture the constrains in the spec files/RPM as they
> > are already capture in the Go source code,
>
>
> In the Go module world the constrains are in the module files, not in
> the source files. If you don't satisfy the constrains in your build
> root
> lots of go commands will break. So you better tell the rpm tooling
> what
> the constrains are so build roots are populated correctly.
>
>
I don't intend to maintain X versions of the same Go package, only in
some
edge case should we have a compat package for an old versions,
otherwise we
should maintain the latest semver release (v1/v2 etc.. too) or the
latest
commit.
Just to be clear, the upstream version range with exclusions model is
intended to make upgrading to new versions safe. By default all deps are
upgradable, an upstream can only exclude a specific set of upgrade
versions.
So unless an upstream wants to watch for every new version or commit of
the projects he uses, and add them to its exclusion list, it needs to
accept they'll be eventually upgraded and the project code better be
ready for it.
(not sure how Go projects will react when they realize Go upstream gave
them a very short rope to hand themselves with, and exclusions do not
lend themselves to blanket version blacklisting).
--
Nicolas Mailhot