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

Drop .doctrine-website.json #380

Open
SenseException opened this issue Jan 21, 2021 · 3 comments
Open

Drop .doctrine-website.json #380

SenseException opened this issue Jan 21, 2021 · 3 comments

Comments

@SenseException
Copy link
Member

SenseException commented Jan 21, 2021

With an organisation wide branch naming (1.0.x, 1.1.x, 2.0.x) it should be possible to work with the metadata of the repositories alone to get the information for the website build of the documentation.

  • The default branch is supposed to hold the current alias and is the supported version
  • Every version number above the default branch name is an upcoming version
  • The highest version branch name above the default branch is the latest version
  • Every branch below the default branch (or tags with versions below) are older and unsupported versions

It suggests that only the versions contained by the default branch is a supported version and that every repository marks only one major (or minor) version as maintained. This is currently not the case for every Doctrine project and unlikely a goal. The possibility of a maintained-versions strategy could cover such cases like: "The default branch version and the branch of the following major version are maintained".

These are just first thoughts about a way that we don't need to maintain a website file for every Doctrine repository anymore.

Edit: This is also an opportunity to check why a GitHub token is needed for open repository metadata.

@stof
Copy link
Member

stof commented Oct 6, 2021

Edit: This is also an opportunity to check why a GitHub token is needed for open repository metadata.

probably a way to avoid rate limiting (the rate limit for the GitHub API is very low for unauthenticated calls)

It suggests that only the versions contained by the default branch is a supported version and that every repository marks only one major (or minor) version as maintained. This is currently not the case for every Doctrine project and unlikely a goal. The possibility of a maintained-versions strategy could cover such cases like: "The default branch version and the branch of the following major version are maintained".

Well, especially for new major versions, providing some overlap for the maintenance windows seems important to me (as migrating is not instant).

The suggested policy would however imply that the default branch has to target the old major version rather than the last one, which seems weird to me from a contributor PoV

@stof
Copy link
Member

stof commented Oct 6, 2021

  • Every version number above the default branch name is an upcoming version

A better policy would be "every version number above the default branch, and without a matching stable relese`, to account for maintaining 2.13.x and 3.0.x in parallel after the 3.0.0 release.

@driehle
Copy link
Member

driehle commented Oct 19, 2021

While I don't like the .doctrine-project.json file either, I'd like to mention that you are using the laminas/automatic-release action in the release workflow. Personally, I think this is great, as it makes releases and the release process much more consistent.

However, in the Laminas ecosphere the default branch is usually the branch of the next, yet unreleased minor version. See, for instance, laminas-form (default: 3.1.x, latest: 3.0.1) or laminas-servicemanager (default: 3.11.x, latest: 3.10.0). With laminas/automatic-release it is possible to have the default branch switched automatically, to keep this consistent over time.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants