Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Default branch for storing the publiccode.yml file #35

Open
libremente opened this issue Feb 13, 2019 · 3 comments
Open

Default branch for storing the publiccode.yml file #35

libremente opened this issue Feb 13, 2019 · 3 comments
Labels
question Questions (to be converted to Discussions)

Comments

@libremente
Copy link
Member

libremente commented Feb 13, 2019

Discussion

Since there are no indications whether the default branch where to store the publiccode.yml file has to be master, maybe the standard should provide more details.
This may be a problem when a repository does not have a branch named master.

@libremente libremente added meta Meta changes not related to the standard itself question Questions (to be converted to Discussions) labels Feb 13, 2019
@sebbalex
Copy link
Member

This needs to be addressed as soon as we can. Many projects are turning to a different default branch naming convention.
cc @libremente @bfabio @alranel

@bfabio
Copy link
Contributor

bfabio commented Aug 20, 2020

Many projects are turning to a different default branch naming convention.

Also GitHub is planning on having main as the default branch soon

@bfabio
Copy link
Contributor

bfabio commented Aug 23, 2020

The obvious and backward compatible thing to do would be adding an optional branch key, but the standard is (purposely?) vague on which VCS are supported, but explicitly references Subversion.

Now, Subversion can address branches in its URLs and I think this is true for Bazaar and Mercurial as well, unlike git.

Do we want to define the supported VCSs in url so we can make better informed decisions with branch key or do we want to be generic and future proof?

If we pick the former we can name the new key gitBranch and have validations in place for invalid cases like using SVN with or without a branch in the URL and a non-empty gitBranch.

If we pick the latter, branch would be "branch for all the VCS that don't allow addressing branches in their URL, ie git 90% of the times".

@bfabio bfabio removed the meta Meta changes not related to the standard itself label Dec 5, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Questions (to be converted to Discussions)
Projects
None yet
Development

No branches or pull requests

3 participants