Clarify reason for 'Develop' rep name and missing plugin changelog org

[theaminulai]

I have a few questions. First, why is the repository named "develop"? All the other repositories are named "trunk"; what makes this one different? for example: https://github.com/WordPress/gutenberg

Also, what is the WordPress.org plugin URL? If it is a URL, I noticed that there is no changelog provided here: https://wordpress.org/plugins/sqlite-database-integration/#developers. for example: https://wordpress.org/plugins/performance-lab/#developers

In WordPress’s SVN structure:

• trunk/ usually contains the stable development version (the one synced to WordPress.org).
• branches/ and tags/ are used for versioning and maintenance.

Note: If you believe this information is incorrect, please feel free to create a task and assign it to me. I’d be happy to look into it and make a contribution.

@JanJakes

[JanJakes]

Hi @theaminuli, thanks for your input!

First, why is the repository named "develop"?

I suppose you meant to refer to the main branch, not the repository. In any case, develop is the main branch at the moment indeed, and I think there is no special reason. It has been like that for a long time. I agree with renaming it; it's just a few clicks in the GitHub UI, but it's more complicated than that, as some projects depend on this repository, and we would break their workflow. It needs to be done in coordination.

All the other repositories are named "trunk"; what makes this one different?

Usually, the main branch in a Git repository is called main. Many repositories also use master. Some use develop, or canary, and other names. In the WordPress world, it's often trunk, as per SVN, although unusual in Git. Ultimately, it's just a name, and it doesn't matter too much.

In WordPress’s SVN structure:

As you mention, this applies to SVN, and it is also the case for this plugin: https://plugins.svn.wordpress.org/sqlite-database-integration/

I noticed that there is no changelog provided here:

This is true at the moment (see #83 and #200). The process will be automated together with the monorepoization and division of the codebase into packages.

I will go ahead and close this issue, as I don't think there's any need to "clarify reason" for a branch name, and for the changelog part, I consider this a duplicate of #83 and #200.