Fabric release-2.5 branch and main branch


David Enyeart
 

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


Baohua Yang
 

Concurrent branches are common practices to handle both latest and stable code.

And I guess many are curious if the release v2.5 will become the new LTS?

Thanks!

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



--
Best wishes!

Baohua Yang


Mark Lewis
 

In the Fabric contributor meeting on 29 June 2022, it was mentioned that Fabric v2.5 is expected to be the next LTS release.

https://wiki.hyperledger.org/download/attachments/62234113/20220629_contributors_meeting.mp4?api=v2


Ry Jones
 

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


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


David Enyeart
 

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

 

 

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


Yacov
 

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

 

 

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


Ry Jones
 

I think moving docs outside the main repo would be great.

Ry Jones
Community Architect, Hyperledger


On Wed, Jul 20, 2022 at 8:55 AM Yacov Manevich <YACOVM@...> wrote:
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

 

 

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


David Enyeart
 

I would certainly consider that. What is the full proposal? What has worked well for other projects?  Could you start a new topic dedicated to the doc proposal?

 

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

I think moving docs outside the main repo would be great. Ry Jones Community Architect, Hyperledger Book a meeting Chat on Discord On Wed, Jul 20, 2022 at 8:55 AM Yacov Manevich <YACOVM@...> wrote: ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍

ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside your organization.

ZjQcmQRYFpfptBannerEnd

I think moving docs outside the main repo would be great.


Ry Jones

Community Architect, Hyperledger

 

 

On Wed, Jul 20, 2022 at 8:55 AM Yacov Manevich <YACOVM@...> wrote:

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

 

 

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