[FOLIO-2478] Release mod-inventory for Q1 2020 Created: 26/Feb/20  Updated: 03/Jun/20  Resolved: 14/Apr/20

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

Type: Story Priority: P2
Reporter: Cate Boerema (Inactive) Assignee: Marc Johnson
Resolution: Done Votes: 0
Labels: release
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Issue links:
Blocks
is blocked by MODINV-271 MatchEngine doesn't process profiles ... Closed
is blocked by MODDICORE-28 Implement processor to handle default... Closed
is blocked by MODINV-198 BE: Preceding titles ability to add "... Closed
is blocked by MODINV-204 Implement InstanceLoader and handler ... Closed
is blocked by MODINV-212 Searches returning more than 50 insta... Closed
is blocked by MODINV-219 Upgrade MODINV's library, based on MO... Closed
is blocked by MODINV-272 Bugfest: Instance relationships not r... Closed
is blocked by MODINV-182 Implement action handler for Create I... Closed
is blocked by MODINV-183 Implement action handler for Create H... Closed
is blocked by MODINV-184 Implement action handler for Create I... Closed
is blocked by MODINV-201 Implement Loaders and MatchHandlers f... Closed
is blocked by MODINV-217 Long instance-relationship query url Closed
Cloners
clones FOLIO-2477 Release mod-codex-inventory for Q1 2020 Closed
Sprint: Core: F - Sprint 85, Core: F - Sprint 86, Core: F - Sprint 84
Story Points: 5
Development Team: Prokopovych

 Comments   
Comment by Ann-Marie Breaux (Inactive) [ 02/Mar/20 ]

HI Marc Johnson I added MODINV-201 Closed , MODINV-204 Closed , MODINV-182 Closed , MODINV-183 Closed , and MODINV-184 Closed as blockers. Realistically, Folijet will get a couple of these done by early next week, but not all 5. Whatever is not done by the time you need to release, we'll aim to ask for BugFix releases as soon as they are done.

cc: Oleksii Kuzminov Kateryna Senchenko

Comment by Marc Johnson [ 03/Mar/20 ]

Thanks Ann-Marie Breaux

Realistically, Folijet will get a couple of these done by early next week, but not all 5. Whatever is not done by the time you need to release, we'll aim to ask for BugFix releases as soon as they are done.

I think that it might be worth me preparing the releases for mod-inventory-storage and mod-inventory early, prior to any of these outstanding changes going in.

Then doing a subsequent release when those changes are in. That way, the 2020 Q1 release isn't blocked by them, neither is it affected by partial functionality.

Rather than this second release being a bug / hot fix release, I suggest we do what we have done in the past for changes that will pass the release deadline, and stop other changes being made to the mainline code until these are ready and do a regular release.

During a conversation with Cate Boerema yesterday, and recent triaged hot fixes, it became clear to me that I have a different understanding of what constitutes a bug / hot fix release. Hence, I will wait for advice from the release triage group before actioning any of this.

Cate Boerema Jakub Skoczen Mark Veksler Anton Emelianov Mike Gorrell What do you think? (If I've missed folks from that group, please include them)

Comment by Cate Boerema (Inactive) [ 03/Mar/20 ]

Hi Marc Johnson. Here is the way I have been using the terms:

  • Bugfix release - Release made after the relevant module has been released for the quarter, but before tenants are live on the new FOLIO version. These releases are usually for fixing bugs but could also be for including other must-have functionality that wasn't complete when the first release was created. Typically these releases include only the required bug fix or new functionality (patch release), but for some fixes, a new full release must be done. I don't know that we have a separate name for the follow-on full releases or if we need one.
  • Hotfix release - Release made after tenants are live which will need to be deployed to production environments.

Hopefully that's generally aligned with how others think about this. Jump in if not.

From my perspective, your plan here is a good one, Marc Johnson. Even though the follow-on MODINV releases will be atypical bugfix releases in that they are not for fixing bugs and they are not patch releases, I think they should follow the same process as any other bugfix release (i.e. they need approval from the #release_bug_triage group)

Comment by Ann-Marie Breaux (Inactive) [ 03/Mar/20 ]

Hi Marc Johnson and Cate Boerema I'm fine with that. It's definitely functionality we need to get into Q1, so I don't want it to get lost. Would it make sense to create a Q1 follow-on release story and re-link these issues to it?

Cate Boerema can I get pre-approval from the release_bug_triage group for these? Without them we cannot finish the work to be able to create instances, holdings, and items in Inventory with proper import mappings.

cc: Oleksii Kuzminov Kateryna Senchenko

Comment by Ann-Marie Breaux (Inactive) [ 03/Mar/20 ]

Also a quick question about preceding/succeeding - yesterday Charlotte Whitt mentioned several stories that she was hoping would be finished in Q1, but I only see one linked here. Are there others that should be linked as blockers?

Comment by Charlotte Whitt [ 03/Mar/20 ]

Ann-Marie Breaux - I have updated FOLIO-2479 Closed Release mod-inventory-storage for Q1 2020

Comment by Ann-Marie Breaux (Inactive) [ 03/Mar/20 ]

Perfect - thank you Charlotte Whitt!

Comment by Marc Johnson [ 19/Mar/20 ]

Cate Boerema Ann-Marie Breaux Mark Veksler Anton Emelianov Jakub Skoczen

To confirm, we are applying an exemption to the quarterly release deadline for mod-inventory in order to allow FoliJet to complete the ongoing changes to mod-inventory?

Whilst that is ongoing, I should limit the merged changes to mod-inventory to only bug fixes we intend to get into 2020 Q1, so that a new mainline release, 14.1.0 or 15.0.0 can be performed when ready.

Is my understanding of the current situation correct?

Comment by Cate Boerema (Inactive) [ 19/Mar/20 ]

That sounds right to me, Marc Johnson

Comment by Marc Johnson [ 21/Mar/20 ]

Hongwei Ji

As per our discussion on MODINV-217 Closed , I have release 14.0.1 which includes the fix for MODINV-212 Closed , meaning we are not dependent upon the timing of the data import work for this issue to be resolved prior to bug fest starting.

Comment by Kateryna Senchenko [ 27/Mar/20 ]

Hi Marc Johnson, I merged the PR for updating data-import-processing-core dependency in mod-inventory ( MODINV-219 Closed ) and closing the issue. mod-source-record-manager has already been released with the same update. I think you can proceed with mod-inventory release at this point. Thank you!

Comment by Ann-Marie Breaux (Inactive) [ 27/Mar/20 ]

Yayyy!!!! Thanks Kateryna Senchenko and thanks Marc Johnson!!

Comment by Marc Johnson [ 28/Mar/20 ]

mod-inventory 14.1.0 has been released which includes the data import work for 2020 Q1.

Comment by Ann-Marie Breaux (Inactive) [ 06/Apr/20 ]

Hi Marc Johnson This was released, per your comment above - right? OK to close it? Might it be helpful to have these in the appropriate projects (e.g. mod-inv) instead of FOLIO? Would that make it easier to keep track of them on team boards? Or maybe FOLIO project tickets show on your team board anyway.

Comment by Marc Johnson [ 08/Apr/20 ]

Ann-Marie Breaux

This was released, per your comment above - right? OK to close it?

mod-inventory has been released multiple times. I've been either keeping these issues open if I expect another release or re-opening them when a new release is needed, as my interpretation of these issues was to track releases during the 2020 Q1 release process.

Might it be helpful to have these in the appropriate projects (e.g. mod-inv) instead of FOLIO?

I don't know. The creation of them was suggested by and done by Cate Boerema because other teams had used release issues.

I don't know if it was intended that they get moved to the individual projects. A challenge with them being in the module projects themselves (a bit like with spikes) is that they confuse the release and version management because they don't have fix versions.

Would that make it easier to keep track of them on team boards? Or maybe FOLIO project tickets show on your team board anyway.

As I understand it, the Core Functional board uses the team field in JIRA and so can include issues from any project.

Cate Boerema did raise a question about how I have been using these issues. Maybe for next quarter, the project can establish a standard process across teams for these kinds of issues e.g. when they should be closed, what project they should be in, etc. Could that be a topic for the retrospective?

Comment by Ann-Marie Breaux (Inactive) [ 08/Apr/20 ]

Hi Marc Johnson Interesting! At least on Folijet (not sure about other teams), we do a new task for each release, in the project that will be released, and tag that task with the release number. Then for any stories/bugs that need finishing before the release, we link them as blockers. That way when all the blockers are done, we know we can make the release. Here's an example: MODSOURMAN-297 Closed

I can see how you would need to manage it differently if using the same Jira for multiple releases of the same module over the course of a quarter.

No worries!

Comment by Marc Johnson [ 08/Apr/20 ]

Ann-Marie Breaux

At least on Folijet (not sure about other teams), we do a new task for each release, in the project that will be released, and tag that task with the release number. Then for any stories/bugs that need finishing before the release, we link them as blockers.

I can see how you would need to manage it differently if using the same Jira for multiple releases of the same module over the course of a quarter.

At a quick count, that means FoliJet has raised at least 16 separate issues to manage the release work for the 2020 Q1 release period alone. Was that the case?

We could raise new release issues for every release. As an example, that would mean that, for only the modules I am the lead maintainer of, there would need to have been at least 16 issues as well.

One of the challenges that we've faced on the Core Functional team, is that because multiple teams work on the modules, it is hard to keep the list of blockers up to date, even on the initial release. My concern with this approach is that it could be significantly more admin.

Comment by Ann-Marie Breaux (Inactive) [ 08/Apr/20 ]

27 since 1 January (https://folio-org.atlassian.net/issues/?jql=text%20~%20release%20AND%20%22Development%20Team%22%20%3D%20Folijet%20AND%20updatedDate%20%3E%3D%20startOfYear()%20AND%20issuetype%20%3D%20task%20ORDER%20BY%20updated%20DESC%2C%20key%20ASC - there's 3 false hits in the list)

It helps us stay organized and track stuff. I can definitely see how it gets tricky when working with lots of POs, plus issues coming at you from other teams.

But absolutely no worries - when it comes to the MOD/UI Inventory stuff, we're happy to follow whatever Jira structure Core-fxn decides on.

Comment by Ann-Marie Breaux (Inactive) [ 08/Apr/20 ]

FWIW, Thunderjet had 51 since 1 January (https://folio-org.atlassian.net/issues/?jql=%20Summary%20~%20release%20AND%20%22Development%20Team%22%20%3D%20Thunderjet%20AND%20updatedDate%20%3E%3D%20startOfYear()%20ORDER%20BY%20updated%20DESC%2C%20key%20ASC - 3 false hits in the list). They are using stories for their release issues, whereas Folijet uses tasks.

I think they're the team that comes closest to Core-fxn in terms of the numbers of modules they are managing.

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