Define a structure for all our projects

[alexmodrono]

In the fall of 2021 we evaluated different structures for GitHub projects, but we did not decide which one to use. Among many of the options debated, these were the ones that excelled:

1. Having the most stable version as the main branch, and branch from it for all the development versions.
2. Having the development versions as the main branch, and each time we finish a release, create a separate branch for it. In this case, users should always checkout from a tag.

Why do we need to bring this up?

Every git repository should follow a structure that makes it easier to work on it and to maintain, even if multiple developers are tasked to tackle a specific feature, bug-fix, and other things of a similar kind. A team that works with a properly structured repository will also save time looking for things and have more time to work on important tasks. The golden rule of productivity is that better organisation leads to better outcomes.

Why should we choose a specific structure right now?

It is without a doubt that we need to have a standard structure to follow in each of our projects for the reasons explained above, and, now that we are starting to have multiple separate projects (such as chica, StylableScrollView, et al.), it is important to have this already solved before we find ourselves with many projects, a situation where implementing these new structures will be more complicated.

What should we do then?

I designed a structure that might suit our needs, and is based in widespread common practices in use in both closed and open-source software. For a deeper insight in how it works, read the following paper: Hyperspace Project Structure Proposal (19 December 2021).pdf

Apart from this, I also want to take this opportunity in this discussion board to raise this issue and decide what we're going to do. Which structure should we follow? Are there any other structures out there that we should consider?

In the nature of open-source, I believe this discussion should be public, and also because this is something that might be of interest to other developers, and who knows, maybe this discussion is of help to many other people out there!

[alicerunsonfedora]

I have two major concerns regarding this approach. First, what happens to the current structure for Hyperspace Desktop? Changing the structure will certainly break systems currently in place to make the desktop version function.

Second, what happens when there isn't a stable version? root will become quickly outdated, and it may give the impression that we aren't actively developing the product. Additionally, we may experience merge conflicts if the changes are too great.

Besides these concerns, I think this will be a good way of structuring our projects moving forward. If this proposal gets approved, I suggest including this in the contribution guidelines.

@Nomad1556, what are your thoughts on the proposal?

[alexmodrono]

As for Hyperspace Desktop, I don't think it is necessary to change it now that it is in maintenance mode and Hyperspace Luna will probably replace it. I believe this should be just for all the projects we create from now on.

Second, what happens when there isn't a stable version?

root should always reflect the latest version available that is not a beta or alpha, so if the latest version that is not in development is, say, 0.1.0, then root should be 0.1.0. Maybe latest stable version might be a bit confusing because what I meant with it is every version that we consider to be ready to be released to the public, even if it is missing some features.

The project is considered unstable when it is missing some of the features that the initial product is expected to have. Until the product does not meet all the requirements, it can not be considered stable. But, regardless of this, any version that is finished should be merged to root, so I don't think root will become updated. It will, though, if we take a lot of time to release a version because it may seem like there are no commits being done, but this can be easily fixed by appending a link to the branch that is currently in development somewhere in the readme, or in some GitHub Issue or whatever.

Anyways, having several branches to develop different versions is a common practice in many different projects, and it does not seem like the project isn't being actively developed even if there is a big lapse between different versions.

Also, close monitoring of the project can be done by periodically posting all our changes in the different accounts the project has in social media.

[alexmodrono]

We also should agree upon standard criteria that the product should meet in order for it to be considered stable.

[alicerunsonfedora]

We also should agree upon standard criteria that the product should meet in order for it to be considered stable.

I feel like this is project-dependent and should be discussed when the project is in ideation stages.