[RFC] Versioning the index with repository branches

[mosteo]

We have not defined a workflow for updating the index format. Currently, when we do breaking changes, we are also breaking all clients until they update. There is also no clean way of doing CI testing of these changes in PRs, and there is a time window, albeit small, where the alire/alire-index are out of sync.

Even if we implement #234 (check the index version before loading it), this will not solve the CI problem. Also, whereas in beta we may want clients to update to the latest version ASAP, once we have a established user base it seems too harsh to suddenly break the index and force everybody to update alr.

All the difficulties arise from having a single master branch of the index, so I want to float the following idea so you can poke holes in it or suggest alternatives:

Let's suppose we have one branch per index version. Also, we hardcode into alr the branch it has to use for the community index. Then, when we want to change the index format, we make a new branch and update alr to match. This way:

Pros:

• Old alr versions continue working transparently with their own index branch.
  • We can detect new branches/versions on alr index --update, and warn the user at that time.
• CI is performed normally against the new index branch, nothing special to do.
• Once the alr PR is merged, new client installations use automatically the latest index.
  • Updated clients detect the obsolete local index via the index metadata version mismatch (#234).

Cons:

• Might this affect the current CI actions run during crate updating?
• This may be moot once the index stabilizes.
  • It seems sensible to be prepared for such breaking changes.

Pinging @Fabien-Chouteau , @pmderodat for feedback.

[Fabien-Chouteau]

One index branch per Alr release sounds like a good solution to me.

And once we have stable releases, breaking dev version is not that huge of a problem.

[pmderodat]

Hello Alex and Fabien,

The goal of this beta period is to have people create a basic Ada ecosystem, i.e. to contribute as many crates as possible. If there are multiple index branches, which one should they use in order to add their crates? If it’s the latest one, early users will still most of the time need to get into the trouble of updating both alr and the index, so I’m unclear if there is a real benefit. What do you think?

[mosteo]

While the beta period is less concerning, we still need something in place for the eventuality of a breakage between stable versions, unless we consider acceptable that users will have to either update alr or be unable to update their index (probably requiring manual checkout of an older version once the breaking commit is pulled).

[mosteo]

Also, I'm not sure having as many crates as possible is the target of the beta; I think it's about finding as many problems/use cases as possible (granted, the more crates, the more likelihood of finding new issues). All these crates require maintenance whenever something breaks, either by us or by the contributors.

[mosteo]

Adopted with #274