[FOLIO-2708] Major/feature releases for quarterly FOLIO releases from master? Created: 29/Jul/20  Updated: 29/Oct/20

Status: Open
Project: FOLIO
Components: None
Affects versions: None
Fix versions: None

Type: Task Priority: TBD
Reporter: Julian Ladisch Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: devdoc
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Issue links:
Relates
relates to FOLIO-2538 Explain additional release procedures... Closed
Sprint:

 Description   

Before Q2 2020 FOLIO had this policy for major/feature releases:

https://dev.folio.org/guides/regular-releases/ :

A typical strategy for a module development is to keep doing the normal work in feature branches and merging to master until its final release and cut-off date.

Hold off feature branches that are not to be included in the release.

https://dev.folio.org/guidelines/release-procedures/#summary-mvn :

Merge temporary release branch tmp-release-X.Y.0 to master.

This advocates feature releases from master (master branch may also be called main, mainline or default).

This was changed for Q2 2020 (MODINVSTOR-536 comment 82656):

Releasing to Q2 2020 or Q2 2020 Hotfix from master is not allowed. Team supposed to create Q2 2020 branch and commit changes to both master and Q2 2020 branch.

Task:
Tech leads and the members of the release group: Please approve or reject this change.
Then update https://dev.folio.org/guidelines/release-procedures/#summary-mvn accordingly.



 Comments   
Comment by Julian Ladisch [ 29/Jul/20 ]

Anton EmelianovMarc JohnsonCate BoeremaJakub SkoczenMark VekslerMike Gorrell Can the tech leads and the members of the release group discuss and either approve or reject this change, and update the policy documentation accordingly?

Comment by Julian Ladisch [ 29/Jul/20 ]

I would like this change being rejected and reverted. Releasing from master is simpler, and it has lower risk because master is deployed to and tested on folio-testing.

Comment by Cate Boerema (Inactive) [ 29/Jul/20 ]

Releasing to Q2 2020 or Q2 2020 Hotfix from master is not allowed. Team supposed to create Q2 2020 branch and commit changes to both master and Q2 2020 branch.

Didn't Anton Emelianov already walk back this statement? See Slack discussion pasted into this comment: https://folio-org.atlassian.net/browse/MODINVSTOR-536?focusedCommentId=130291&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel

My guess is that there was never really a Q2 policy change, just a comment left in haste which was subsequently reversed based on sensible input from others in MODINVSTOR-536 Closed .

My feeling is that, to the extent possible, we should be making patch releases for hotfixes. But, this can be much harder/riskier for backend modules than frontend ones and, given that, we should have the flexibility to release from master (a release branch that is identical to master) when the relevant tech leads think it's best (with approval from #release_bug_triage group). This is the approach we have always taken, it has served us well and I don't see any reason to change.

Let me know if I am not understanding.

Comment by Marc Johnson [ 29/Jul/20 ]

Didn't Anton Emelianov already walk back this statement?

I don't think folks interpreted it that way, given the way the release was performed.

The release yesterday was made in the non-standard way that Julian Ladisch suggested using a branch that had the same starting point as the mainline (however never rejoined mainline). I believe it was done that way in order to be compliant with Anton Emelianov's statement. (Anastasiia Zakharova Oleksandr Yatsenko Julian Ladisch please advise if my interpretation of your comments and our conversations is incorrect).

we should have the flexibility to release from master (a release branch that is identical to master)

My understanding of how the comments by Anton Emelianov and Julian Ladisch have been interpreted is that a release from the mainline (in the sense that it follows our regular release procedure) and a release from a branch with an identical starting point to the mainline are considered different.

I tried to express those differences in my follow up comment on MODINVSTOR-536 Closed . I get the sense that my explanation did not come across to folks.

Comment by Zak Burke [ 31/Jul/20 ]

It isn't clear to me that we will benefit from having strong rules/policy around what branches releases are tagged on. As Julian Ladisch noted, there is great appeal in releasing from master because it is deployed to the reference environments and enjoys widespread use, and therefore widespread manual testing.

But mandating that we release only from master is, I think, impractical. As soon as we make a rule like that, we'll find we need to make an exception to it – there are always exceptions; it is the way of things – and then there will be much hand wringing about what to do, which could be avoided if we had just avoid the overly-strict policy in the first place.

We continue to vigilantly pursue increased test coverage across all repositories. Hopefully, such automated testing will soon provide even better coverage than the de facto manual testing on the reference environments, and we'll feel confident about releasing from any branch where those tests pass.

Comment by Julian Ladisch [ 31/Jul/20 ]

This issue is not about mandating to release only from master.
This is not possible if the commits to be released and other commits not to be released are intermixed on master; this always requires a separate branch.
This issue is about allowing to release from master for the case that all commits on master are to be released.

Comment by Marc Johnson [ 14/Oct/20 ]

Anton Emelianov Craig McNally Jakub Skoczen Julian Ladisch

I'm resurrecting this topic as it has come upon again (see CIRC-936 Closed for context) and I don't feel I have clear guidance to give.

I'm going to outline an example and ask for folks views on which approaches are acceptable.

Situation

The last release of a module is 5.3.0.

There have been various changes to the mainline, lets call them A, B, C and D

Goal

To make a release containing new features B and D

Options

  1. Make a feature release (5.2.0) from the mainline.
  2. Make a feature release (5.2.0) from a new long lived branch (b5.2, based upon the 5.1.0 release). Separate change needed on the mainline to move the next version to 5.3.0.
  3. Make a feature release (5.2.0) from a new long lived branch (b5.2, based upon the latest revision of the mainline that is appropriate, after the v5.1.0 release). Separate change needed on the mainline to move the next version to 5.3.0.
  4. Make a bug fix release (5.1.1) from a long lived branch (b5.1) based upon the 5.1.0 release. This would disguise the new features as a bug fix.

The release from option 1 would also include other changes A and C. The releases from options 2, 3 and 4 would only includes changes B and D (usually caveats about cherry picking / merges still apply).

Questions

Which of these options are acceptable choices for a lead maintainer / developer to make?

If folks consider option 1 to be unacceptable in the above example, would it be acceptable if the only changes on the mainline were B and D?

cc: Former user Viachaslau Khandramai

Comment by Craig McNally [ 29/Oct/20 ]

This is my take on this... I'd love to hear other's opinions though

I think it depends on if features A and C include breaking compatibility changes, doesn't it?

Assuming that there's a reason to NOT include A and C in this release, I personally would go with option 2 unless option 3 didn't require cherry picking - that is there's a revision of mainline which has the features you want and doesn't have the features you don't want.

I would stay away from option 4. Disguising features as bugs is unacceptable IMO.

Generated at Thu Feb 08 23:22:39 UTC 2024 using Jira 1001.0.0-SNAPSHOT#100246-sha1:7a5c50119eb0633d306e14180817ddef5e80c75d.