Skip to content

Commit d1ed5a4

Browse files
authored
Add decision log for migration tool (#4853)
1 parent 9d5ade0 commit d1ed5a4

File tree

1 file changed

+31
-0
lines changed

1 file changed

+31
-0
lines changed
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,31 @@
1+
# Decision Log for AWS SDK fro Java v2 Migration Tool
2+
3+
## Log Entry Template
4+
5+
**Source**: (Meeting/aside/pair programming discussion/daily standup) to (discuss/implement) X
6+
7+
**Attendees**: Anirudh, Anna-Karin, David, Dongie, Debora, Olivier, Matt, Jason, John, Zoe
8+
9+
**Closed Decisions:**
10+
11+
1. Question? Decision. Justification
12+
13+
**Open Decisions:**
14+
15+
1. (Old/Reopened/new) Question?
16+
17+
## 01/26/2024
18+
19+
**Source:** Daily standup and offline discussion to discuss where we should host the source code of the v2 migration tool
20+
21+
**Attendees:** Anna-Karin, David, Debora, Olivier, Matt, Jason, John, Zoe
22+
23+
**Closed Decisions:**
24+
25+
1. Should we host the source code in the same aws-sdk-java-v2 repo? Yes, because 1) no extra release infrastructure is needed since it can be released as part of the SDK release 2) it's easier to write scripts to generate recipes, for example, we need to write script to retrieve service IDs for all services and current version. 3) it has better discoverability. The only disadvantage is that it will increase the scope of the repo and increase the build and release time slightly. The alternatives are: 1) setting up a new GitHub repo, which require us to set up and maintain new CICD pipeline. 2) hosting the code internally, which would be a bad customer experience since the code is not public and there is no place for users to raise questions/PRs.
26+
27+
2. Should we publish the tool to Maven central instead of vending a JAR through S3? Yes, because most customers, if not all, prefer to consume the library from the package manager instead of a JAR.
28+
29+
**Open Decisions:**
30+
31+
None

0 commit comments

Comments
 (0)