PRs have started coming in for Fabric v3.0, e.g. removal of already deprecated features like Kafka ordering and system channel, as discussed in contributor meetings. So as to not impact the next v2.x release (v2.5), we have created a release-2.5 branch from the current main branch. We are not currently planning on a v2.6 release, but if we do have a v2.6 in the future we have the option to create a release-2.6 branch from where release-2.5 leaves off.

 

Which branch to target in a PR?

• PRs intended for v3.0 should target main branch.
• PRs intended for v2.x should target release-2.5 branch.
• PRs intended for both should continue to target main branch and then be backported to release-2.5.

 

The plan is still to deliver the Purge Private Data feature in v2.5. For this feature PRs can target release-2.5 branch to streamline final development, and then be forward ported to main branch.

 

While this change will require a little more due diligence around PR contributions and merges, it enables the community to make concurrent forward progress on both v2.5 work items and v3.0 work items.

 

Taking a step back, we have practiced trunk-based development in Fabric for many years with success (essentially two trunks now – release-2.5 and main). We’ve found that it streamlines development when sufficient safeguards are in place (e.g. automation test with good coverage within and across repositories, thorough code reviews from maintainers). That being said, where it makes sense we can also create individual feature branches when we want to isolate new development. For example a disruptive change intended for v3.0 could be worked on in a feature branch first to assess the implementation, and then later merged into main branch.

 

We plan to expand the Fabric readme and contribution guide with the above information. But let’s first see if there is any other feedback to consider and include.

 

Thanks,

 

Dave

PRs have started coming in for Fabric v3.0, e.g. removal of already deprecated features like Kafka ordering and system channel, as discussed in contributor meetings. So as to not impact the next v2.x release (v2.5), we have created a release-2.5 branch from the current main branch. We are not currently planning on a v2.6 release, but if we do have a v2.6 in the future we have the option to create a release-2.6 branch from where release-2.5 leaves off.

 

Which branch to target in a PR?

• PRs intended for v3.0 should target main branch.
• PRs intended for v2.x should target release-2.5 branch.
• PRs intended for both should continue to target main branch and then be backported to release-2.5.

 

The plan is still to deliver the Purge Private Data feature in v2.5. For this feature PRs can target release-2.5 branch to streamline final development, and then be forward ported to main branch.

 

While this change will require a little more due diligence around PR contributions and merges, it enables the community to make concurrent forward progress on both v2.5 work items and v3.0 work items.

 

Taking a step back, we have practiced trunk-based development in Fabric for many years with success (essentially two trunks now – release-2.5 and main). We’ve found that it streamlines development when sufficient safeguards are in place (e.g. automation test with good coverage within and across repositories, thorough code reviews from maintainers). That being said, where it makes sense we can also create individual feature branches when we want to isolate new development. For example a disruptive change intended for v3.0 could be worked on in a feature branch first to assess the implementation, and then later merged into main branch.

 

We plan to expand the Fabric readme and contribution guide with the above information. But let’s first see if there is any other feedback to consider and include.

 

Thanks,

 

Dave

I agree.

I also always said that documentation shouldn't belong in the Fabric core repository in the first place.

---

From: fabric@... <fabric@...> on behalf of David Enyeart <enyeart@...>
Sent: Wednesday, July 20, 2022 6:37 PM
To: Ry Jones <rjones@...>
Cc: fabric@... <fabric@...>; Community Architects <community-architects@...>
Subject: [EXTERNAL] Re: [Hyperledger Fabric] Fabric release-2.5 branch and main branch

 

I am not in favor of moving i18n translations to fabric core repo. There are assumptions that everything in fabric core repository should stay in sync and up to date including features, tests, and doc. This is not possible for i18n content.

ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside your organization.

 

ZjQcmQRYFpfptBannerEnd

I am not in favor of moving i18n translations to fabric core repo.

• There are assumptions that everything in fabric core repository should stay in sync and up to date including features, tests, and doc. This is not possible for i18n content.
• We have worked to reduce the content of fabric core to keep it as streamlined and stable as possible with minimal churn. i18n commits would add constant churn and far outnumber core commits, making the core commit history difficult to parse and understand.
• The fabric maintainers don’t have bandwidth or language skills to oversee i18n.
• I have not seen i18n translations in many other project’s core repositories.

 

 

From: Ry Jones <rjones@...>
Date: Wednesday, July 20, 2022 at 9:54 AM
To: David Enyeart <enyeart@...>
Cc: fabric@... <fabric@...>, Community Architects <community-architects@...>
Subject: [EXTERNAL] Re: [Hyperledger Fabric] Fabric release-2.5 branch and main branch

Hi Dave, I think it's time to consider merging the work of the Fabric i18n work with the main repo. Keeping that repo in sync with the main repo is error-prone and hard. I'm willing to do the typing to move the content over, preserving

ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender This message came from outside your organization.

ZjQcmQRYFpfptBannerEnd

Hi Dave,

I think it's time to consider merging the work of the Fabric i18n work with the main repo. Keeping that repo in sync with the main repo is error-prone and hard.

I'm willing to do the typing to move the content over, preserving history. It would mean moving the english documentation down to a locale, which I already did.

Ry

Ry Jones

Community Architect, Hyperledger

Book a meeting Chat on Discord

 

 

On Tue, Jul 19, 2022 at 8:39 AM David Enyeart <enyeart@...> wrote:

PRs have started coming in for Fabric v3.0, e.g. removal of already deprecated features like Kafka ordering and system channel, as discussed in contributor meetings. So as to not impact the next v2.x release (v2.5), we have created a release-2.5 branch from the current main branch. We are not currently planning on a v2.6 release, but if we do have a v2.6 in the future we have the option to create a release-2.6 branch from where release-2.5 leaves off.

 

Which branch to target in a PR?

• PRs intended for v3.0 should target main branch.
• PRs intended for v2.x should target release-2.5 branch.
• PRs intended for both should continue to target main branch and then be backported to release-2.5.

 

The plan is still to deliver the Purge Private Data feature in v2.5. For this feature PRs can target release-2.5 branch to streamline final development, and then be forward ported to main branch.

 

While this change will require a little more due diligence around PR contributions and merges, it enables the community to make concurrent forward progress on both v2.5 work items and v3.0 work items.

 

Taking a step back, we have practiced trunk-based development in Fabric for many years with success (essentially two trunks now – release-2.5 and main). We’ve found that it streamlines development when sufficient safeguards are in place (e.g. automation test with good coverage within and across repositories, thorough code reviews from maintainers). That being said, where it makes sense we can also create individual feature branches when we want to isolate new development. For example a disruptive change intended for v3.0 could be worked on in a feature branch first to assess the implementation, and then later merged into main branch.

 

We plan to expand the Fabric readme and contribution guide with the above information. But let’s first see if there is any other feedback to consider and include.

 

Thanks,

 

Dave