Updated dependencies to community versions

[dannys42]

No description provided.

[futurejones]

@dannys42 @fouadhatem @mbarnach If you push these changes I think you will break everything. The 200 package versions you are referencing don't exist yet.

First: All individual repos need to be updated the reflect the new Kitura organization. This needs to be complete, not just a few package references.

Next: Confirm Travis builds and tests are passing on all the individual repos.

Then: Release a new version with your 200 version number on all the individual repos.

Finally: Now the dependancies can be updated to the new versions.

[fouadhatem]

@futurejones Can you please elaborate on this:

"First: All individual repos need to be updated the reflect the new Kitura organization. This needs to be complete, not just a few package references."

[futurejones]

@fouadhatem If we only update partly, but still have references to IBM-Swift in README's and docs, then push an update then the update will still contains all the old refs to IBM-Swift. This doesn't make much sense as the purpose of the update is to make a break point and reflect the new Kitura Organization.
This also makes it easier to know which repos have been fully migrated.
At the moment there are large number of repos that have had some updates done but still need finishing. There is no way to identify which or what has been done as nobody is posting what they have been doing or what still needs to be done.
Even if you check all the repos individually this still only tells you if a PR has been submitted not whether somebody is currently working on it.

[dannys42]

@futurejones I posted this in another PR, but adding here since there's more conversation...

I did create tags, which is all that SPM cares for (note that CI did pass successfully). It's a good point that I hadn't checked GitHub releases, though. I'm not sure if there's really a reason to support GitHub releases, other than visibility. But GitHub already lists tags there, so I'm not sure there's a huge issue. I see that OpenSSL doesn't even have releases for many of the prior tags. If we want to continue GitHub releases, perhaps we can just do it for major or minor releases, but not normally for patch releases (with perhaps the exception of this community release)? I think the main benefit is perhaps calling out major release notes. But I don't know who wants .zip/.tgz's of individual releases?

As you outlined, care must be taken in making these tags... which is why this has been a bit of a slow process (I've been waiting for the org changes to be finished). But we're at a point now where I can start addressing the version bump for certain repos (which will resolve some of the existing CI builds). I've been following this basic strategy:

1. Pick a repo with few dependencies and ideally only 1-level deep
2. Ensure all org changes are merged for all dependent repos (README's are good, but not strictly required)
3. Tag all dependent repos
4. Update the dependency for the "parent" repo (the one selected in step 1)
5. Submit the PR
6. Go back to step 1 until we have all those repos.
7. Go back to step 1 and go 2-levels deep.
8. repeat

So this will be a fairly slow process. I'm not sure if it's easily distributable either since there's a lot of detailed compare and check against dependencies. I suppose if someone wants to map out a dependency tree, we might be able to distribute the work. But I suspect it'll be faster to just do the work.

[futurejones]

Totally disagree your view on tagging. It doesn't matter whether it is a major or minor, they are all releases and should be treated as such. Whether somebody wants .zip/.tgz's is irrelevant. The key point is visibility.
Just tagging doesn't make any sense and in my view is wrong.

[futurejones]

@dannys42 I think your work plan is unnecessarily complicated and makes it near impossible to know what is in progress and what still needs to be done.

1. No releasing/tagging should be done until all repos are updated.
2. A list of who and what is being done needs to be created.
3. From that list we can ascertain what still needs to be done.
4. Allocate these jobs to who ever want's to do them.
5. When all repos are fully updated, then we can look at progressively creating releases for all the repos with the new 200 tag.
   This does need to include ReadMe's and all docs - No point releasing an update for the change to the new organization if its still referencing the old one.

[dannys42]

The problem with that approach is that all the PR's will be failing until you're at the end. At which point you still have to go in a breadth-first, bottom-up fashion. It also gates our ability to complete by having every single repo fully transitioned and passing CI. Some repos will take longer because of added dependencies (e.g. external services, understanding of what's needed, etc.) and those repos aren't necessarily core functionality.

The approach I suggested ensures that each subtree (in the graph of all repos in the org) is complete and working. And allows us to get the core components up and running as soon as possible. If you want, we can still have a master list of all repos and just put a checkmark next to the ones that are done. That will solve the visibility issue.

As for releases, in a pure "git" world, only tags/branches matter, so I don't have as strong a view on that. But I concede your point on visibility, so I'll agree to the process of making GitHub releases standard.

[dannys42]

I think this is kind of an important topic, so I'd like to move this to our discussion board to make it easier for everyone to weigh in.

[futurejones]

Good idea to move to discussion board.
Just a note: None of the PR's will fail because we are not initially changing any version numbers. All the package links will still be pointing to the existing releases. There is actually no need to create any new versions to complete the migration.

[mbarnach]

@dannys42 @futurejones Just to be clear: we are talking about updating the version in the dependencies? Like this PR? Or are we talking also about creating the tags/release for the repositories themselves?
I consider these are highly different: the tag is "human-readable" for now: we know the repo has been updated, and we can move on to the next one. The dependency is not required as (correct me if I'm wrong) all the packages use the from approach (plus there is no changes) and will pickup the latest patch version when "refreshed" or newly created.

I'm tempted to hold on for the version. In my experience, there is always hiccups and things we overlook. Then we will ends up with 201, 202, etc. Especially with so many packages. Not to mention places where eg, we forget to update kitura.io to kitura.dev. I think having the pointers updated and start adding new PR, contacting authors of old one, etc. could make the project more visible and more alive.

@futurejones One extra question: do you think we should use Github Release for every single tags? There is 2 fights in my mind constantly with that: on one hand, you want to publish a patch almost every time a PR is merged. But then the release notes are basically the PR. On the other hand, it does make it more visible and professional, which is what we are all after.
I think once we are done with the pointers, we can re-assess and split that work easily (as it is massively parallel).

[sonarqubecloud]

Kudos, SonarCloud Quality Gate passed!

0 Bugs
0 Vulnerabilities (and 0 Security Hotspots to review)
0 Code Smells

No Coverage information
100.0% Duplication