[documentation] Iroha-SDK release interdependency

[Mingela]

Documentation URL(s)

https://github.com/hyperledger/iroha/blob/iroha2-dev/docs/source/release_procedure.org

[AlexStroke]

New Release Process Description: Feature-Driven and Collaborative

In our updated software development release process, we've transitioned away from the rigid monthly cadence to a more flexible and feature-driven approach. This change is aimed at improving overall efficiency, reducing delays, and ensuring consistency in our SDKs (Java, JS/TP, Python) versioning.

1. Release Window Initiation:

• Release windows will no longer be tied to a fixed monthly schedule. Instead, the decision to open a release window will be made by the Iroha 2 Tech Lead.
• The Tech Lead will determine which features are to be included in the upcoming release candidate based on project priorities and objectives.

2. Extended Release Window:

• Once the release window is opened, it will remain open until all SDKs are in good shape and meet the required quality standards.
• This departure from the fixed closure date allows for greater flexibility, ensuring that the SDKs align seamlessly with the core team's developments.

3. Pre-Release Call Facilitation:

• The Project Manager will play a key role in coordinating the pre-release call, which will be held shortly after the release window opens.
• During this call, the Iroha 2 Core Tech Lead will address potential breaking API changes and provide insights into the upcoming release.
• SDK maintainers will participate in this call, allowing for collaborative discussions and clarifications on the integration process.

4. Estimation and Alignment:

• One of the primary goals of the pre-release call is to estimate the time required for SDK maintainers to catch up with the current version of the Core team.
• This estimation process will help in setting realistic expectations and timelines for each SDK's development cycle.

By adopting this feature-driven approach and maintaining an open release window until all SDKs are ready, we aim to achieve smoother and more synchronized releases. This process encourages closer collaboration between the core team and SDK maintainers, reducing delays and enhancing the overall quality of our software. It also allows us to respond to changing priorities and market demands more effectively.

Stage	Who Does It	What To Do
1	Project Manager	Conduct a pre-release// Estimation sync meeting.
2	Project Manager	Form a proper GitHub release and provide links in relevant chat.
3	Project Manager & Tech Lead	Allocate resources for SDK updating
4	Tech Lead	Appraise all present of main API-breaking changes requiring attention.
5	Tech Lead	Walk through the difference between iroha2-stable and iroha2-dev branches.
6	Tech Lead	Create a Pull Request from iroha2-dev to iroha2-stable with the release checklist.
7	Tech Lead & Tribe Lead	Confirm that SDKs are updated and functioning; otherwise, move to an internal release.
8	Tech Lead & Tribe Lead	Close the release window upon completing the release checklist.
9	Tech Lead	Sign off on a release and announce the opening of the release window.
10	SDK Engineers	Update SDKs (Kotlin/Java, JS/TS, Python, Swift) for compatibility with upcoming Iroha release.
11	Core Team Developer	Review and tick off points on the release checklist related to SDK updates.
12	Core Team Developer	Report any major breakages in the relevant chat and respond to inquiries about changes.
13	Core Team Developer	Produce standard packages (Nix, AppImage, .deb, .rpm) and upload to relevant locations.
14	DevOps	Release a nightly docker container through the continuous delivery system.
15	QA Engineer	Update Iroha-related tools like iroha-squash for new SDK versions.

[Mingela]

@dmitrivenger should we close that?

[Mingela]

closing in favor of hyperledger-iroha/iroha-rfcs#10