Skip to content
This repository has been archived by the owner on Dec 2, 2024. It is now read-only.

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

Merged
merged 2 commits into from
Jul 15, 2022
Merged

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

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
4bfac9d
Added precision on the meaning of the first-major version of plutus-apps
koslambrou Jul 15, 2022
62c6dd7
Update README.adoc
koslambrou Jul 15, 2022
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
10 changes: 8 additions & 2 deletions README.adoc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -65,14 +65,20 @@ The core `plutus-apps` packages are versioned as follows:

* Package versioning follows the https://pvp.haskell.org/[PVP] on a best-effort basis (i.e. we will generally try to but we won't guarantee it).
** The first-major-version component indicates the "era" which for our purposes means which major version of the *Cardano node* the tools are compatible with.
*** Alonzo era: `v0.x.x`
*** Babbage era: `v1.x.x`
** The second-major-version component is used for releases which are major versions according to the PVP, but which are still compatible with the current "era".
** The minor-version and below are used as normal.
* Packages which are used downstream should all have the same version.
* Other packages which are not used downstream (e.g. `plutus-playground-server`, `plutus-playground-client`, `quickcheck-dynamic`, etc.) can remain unversioned.

In principle we could just have a single major version, but using two makes it easier to avoid mistakes and clearly expresses the state of the repository.

=== Branching
=== Branching and tagging

The following tagging rules are followed:

* Version `X` is tagged as `vX`

There are two protected branches in `plutus-apps`:

Expand All @@ -82,7 +88,7 @@ There are two protected branches in `plutus-apps`:
** The version of transitive dependencies (`plutus`, `cardano-ledger`, `ouroboros-network`, etc.) should be pinned to the ones from `cardano-node` (or better, `cardano-wallet`)
** Changes will be backported form `main` to `next-node`
* `next-node` branch: should always target the next node release.
** This branch will eventually be merged in `main` after the Cardano mainnet HF.
** This branch will eventually be merged in `main` after the Cardano mainnet HF and deleted. Once the next HF is planned, it will be recreated and it will contain an upgraded `cardano-node` version.
Comment on lines -85 to +91
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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. :)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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. 👍

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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


=== Dependency update

Expand Down