Draft a vendor update policy #58

New Issue

GiteaMirror · 2025-11-02T03:06:28-06:00

GiteaMirror commented

2025-11-02 03:06:28 -06:00

Originally created by @strk on GitHub (Nov 15, 2016).

Originally assigned to: @strk on GitHub.

We need to define a policy for updating the vendor/ directory.
I propose it's written in a vendor/README.md file.
My proposal for a policy is:

vendor/ is only updated when needed to fix a bug or to implement a feature.
when bugfix or feature also require changes to the gitea/ codebase, the updating PR should include both vendor/ and local file changes
when bugfix only requires upgrading of the vendor, the PR should only include the vendor update
reviewer should check to make sure the updates under vendor/ really match an upstream commit before approving the changes

Originally created by @strk on GitHub (Nov 15, 2016). Originally assigned to: @strk on GitHub. We need to define a policy for updating the vendor/ directory. I propose it's written in a vendor/README.md file. My proposal for a policy is: - vendor/ is only updated when needed to fix a bug or to implement a feature. - when bugfix or feature *also* require changes to the gitea/ codebase, the updating PR should include both vendor/ and local file changes - when bugfix only requires upgrading of the vendor, the PR should only include the vendor update - reviewer should check to make sure the updates under vendor/ really match an upstream commit before approving the changes

GiteaMirror added the type/proposal label 2025-11-02 03:06:28 -06:00

GiteaMirror closed this issue

2025-11-02 03:06:28 -06:00

GiteaMirror commented

2025-11-02 03:06:29 -06:00

@metalmatze commented on GitHub (Nov 15, 2016):

We could also update minor versions of our dependencies.
I think it's the responsibility of the merger to make sure that updated dependencies don't break anything. Additionally PR creator can help with that by providing more info about why the dependency was updated.

@metalmatze commented on GitHub (Nov 15, 2016): We could also update minor versions of our dependencies. I think it's the responsibility of the merger to make sure that updated dependencies don't break anything. Additionally PR creator can help with that by providing more info about why the dependency was updated.

GiteaMirror commented

2025-11-02 03:06:29 -06:00

@strk commented on GitHub (Nov 16, 2016):

I agree about the possibility to update minor versions, but it still needs a justification to update (so yes, would need to be written in the PR).

And yes, merger should also check the update doesn't break anything, but the important point to me is that the matching with upstream version is checked, to avoid having local-only changes (as it happened when lint errors were fixed). Do you agree on that part ? (ie: no local-only modifications)

@strk commented on GitHub (Nov 16, 2016): I agree about the possibility to update minor versions, but it still needs a justification to update (so yes, would need to be written in the PR). And yes, merger should also check the update doesn't break anything, but the important point to me is that the matching with upstream version is checked, to avoid having local-only changes (as it happened when lint errors were fixed). Do you agree on that part ? (ie: no local-only modifications)

GiteaMirror commented

2025-11-02 03:06:29 -06:00

@stevenroose commented on GitHub (Nov 16, 2016):

Doesnt a VENDORING.md file in the main folder make more sense, since people tend to ignore the vendor/ directory? (cfr docker)

@stevenroose commented on GitHub (Nov 16, 2016): Doesnt a `VENDORING.md` file in the main folder make more sense, since people tend to ignore the `vendor/` directory? ([cfr docker](https://github.com/docker/docker/blob/master/VENDORING.md))

GiteaMirror commented

2025-11-02 03:06:29 -06:00

@strk commented on GitHub (Nov 16, 2016):

Good idea, +1 for VENDORING.md

@strk commented on GitHub (Nov 16, 2016): Good idea, +1 for VENDORING.md

GiteaMirror commented

2025-11-02 03:06:29 -06:00

@metalmatze commented on GitHub (Nov 16, 2016):

We already have a lot of files in the root. Let's just add a section to the README.md that tells which vendoring tool gitea uses. I don't see the need for a extra file.

@metalmatze commented on GitHub (Nov 16, 2016): We already have a lot of files in the root. Let's just add a section to the `README.md` that tells which vendoring tool gitea uses. I don't see the need for a extra file.

GiteaMirror commented

2025-11-02 03:06:30 -06:00

@strk commented on GitHub (Nov 16, 2016):

Le'ts move this to #187, where I added a vendoring section to the CONTRIBUTING.md file (which is linked from the PR template)

@strk commented on GitHub (Nov 16, 2016): Le'ts move this to #187, where I added a vendoring section to the CONTRIBUTING.md file (which is linked from the PR template)

GiteaMirror referenced this issue

2025-11-02 11:39:17 -06:00

[PR #58] [MERGED] Integrated dependency manager #15118

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/gitea#58