Added precision on the meaning of the first-major version of plutus-apps

[koslambrou]

Pre-submit checklist:

• Branch
  • Tests are provided (if possible)
  • Commit sequence broadly makes sense
  • Key commits have useful messages
  • Formatting, PNG optimization, etc. are updated
• PR
  • Self-reviewed the diff
  • Useful pull request description
  • Reference the ADR in the PR and reference the PR in the ADR (if revelant)
  • Reviewer requested

[ghost]

I think that the process is fine but maybe we can do it better?

The branch is temporary, yes. But turns out people still use it to upgrade their code to iterate quickly. And by removing it we can break someone's code. Maybe instead of next-node we should name the branch moving-to-vasil and each HF with it's own name. We can save these branches forever or for some time, to declare the period of time to give some space to stop using it.

My intention here is to help users not to break their code as they use the commit hashes from different branches. Yes, it's, in some sense, their problem. But I think that we can bring such policies to hardfork branches as they special in that sense and be more user-friendly. Just thoughts.

Also I wanted to propose keeping the log of hardforks to track the changes but then I realised that that's why we want to introduce the CHANGELOG. :)

[koslambrou]

The branch is temporary, yes. But turns out people still use it to upgrade their code to iterate quickly. And by removing it we can break someone's code. Maybe instead of next-node we should name the branch moving-to-vasil and each HF with it's own name. We can save these branches forever or for some time, to declare the period of time to give some space to stop using it.

The idea is that once a HF happens on mainnet, next-node is merged in main. Therefore, there's no point in continuing to work with next-node. Plus, keeping next-node will mean that we need to regularly merge main into next-node. Therefore, I don't think removing next-node will affect anyone since all the changes were merged in main. Additionally, this would be transparent to users once we start consistently using versions as releases, then the user wouldn't need to worry about branch conventions (only the contributor).

I'm not against explicitly naming the branch to something like moving-to-vasil. I guess the idea of always using the same branch name (next-node) would give us some consistency for all HFs so the users know what to expect (instead of having to remember to update the docs at every HF saying the branch name used for the next HF). What do you think?

My intention here is to help users not to break their code as they use the commit hashes from different branches. Yes, it's, in some sense, their problem. But I think that we can bring such policies to hardfork branches as they special in that sense and be more user-friendly. Just thoughts.

So, as users move away from using commit hashes once we use release consistently, it will solve most of these problems.

Also I wanted to propose keeping the log of hardforks to track the changes but then I realised that that's why we want to introduce the CHANGELOG. :)

Yep! I was going to bootstrap CHANGELOGs, but people in our team made some compelling arguments for Github releases instead, so we'll need to take some time to note the pros and cons of each and make a decision.

[ghost]

Therefore, I don't think removing next-node will affect anyone since all the changes were merged in main.

Yeah, I remembered that we use merge commits and as long as we merge the next-node into main without loosing the commits from next-node the users should be fine.

I'm not against explicitly naming the branch to something like moving-to-vasil. I guess the idea of always using the same branch name (next-node) would give us some consistency for all HFs so the users know what to expect (instead of having to remember to update the docs at every HF saying the branch name used for the next HF). What do you think?

Let's see how it goes, I think, adapting to the community's feedback. 👍

[koslambrou]

Alright then. I'll leave it as is and community feedback would definitely help in this case.