[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: |
|
||||||||
| Sprint: | |||||||||
| Description |
|
Before Q2 2020 FOLIO had this policy for major/feature releases: https://dev.folio.org/guides/regular-releases/ :
https://dev.folio.org/guidelines/release-procedures/#summary-mvn :
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):
Task: |
| 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 ] |
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
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 ] |
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).
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
|
| 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. |
| 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
I'm going to outline an example and ask for folks views on which approaches are acceptable. SituationThe 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 GoalTo make a release containing new features B and D Options
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). QuestionsWhich 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? |
| 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. |