Define Folder Structure and Versioning System for Multi-Project Repo

[sergiotejon]

Example context
This is an example
In our example multi-project repository, different projects are located in the cmd/ directory, each with its own .version.json file to manage versions. Internal and common packages are organized under the internal/ and pkg/ directories. While this structure works well, there is currently no standardized method to define and manage the versioning of individual projects, making it difficult to track and update versions systematically.

Problem
Projects are organized under cmd/ with individual .version.json files for version tracking.
The internal/ directory contains internal packages specific to each project, while pkg/ holds common and public packages.
We lack a system to define the structure and versions of all projects, making it harder to automate version bumps and updates across projects like this.

Proposed Solution
We need a mechanism to:

• Define each project’s structure within a .version.json file that can manage different folders in the repository to control the current version.
• Standardize the way we manage versions across multiple projects.
• Ensure versioning consistency, allowing us to track versions for each project more efficiently.

Folder structure:

repo-root/
│
├── cmd/
│   ├── project-A/
│   │   ├── main.go
│   │   └── .version.json
│   ├── project-B/
│   │   ├── main.go
│   │   └── .version.json
│   ├── project-C/
│   │   ├── main.go
│   │   └── .version.json
│
├── internal/
│   ├── project-A/  # internal packages for project-A
│   ├── project-B/  # internal packages for project-B
│   ├── project-C/  # internal packages for project-C
│   ├── pkg/        # shared common internal packages
│
├── pkg/  # public packages shared across projects
│
├── go.mod

Proposed .version.json File
In this proposal, each project retains its own .version.json file with a new folders item to manager the folders the project need and maintain the version properly:

{
  "version": "1.0.0",
  "commit": "76ada272285ea6a513c80bce7fa280af8d06f34a",
  "path": "cmd/project-A",
  "folders": ["internal/project-A", "internal/pkg", ...]
}

folders could be optional, that way the program does not break the previous version, using the current directory as the main dir for the source code of the project, as it is working currently.