Restructure Flogo repos

[mellistibco]

Currently all of the Flogo repos are under the TIBCOSoftware organization. To better organize everything Flogo, we should reorganize the repos and place them within the project-flogo organization on GitHub.

Note that the repo reorg will also be part of a larger Flogo release, as we continue to move toward a 1.0.0 release!

The following list of items need to be considered when we're reorganizing the repo structure.

• Due to the nature of Go import paths being that of the repo, we need to maintain backward compatibility, as such, the TIBCOSoftware/flogo-* repos must be maintained.
• project-flogo/contrib should be used only for minimal, basic Flogo contributions (activities, triggers and expression functions). Larger activities should be broken out into dedicated repos to enable a better versioning scheme.
• Flows, Streams, Rules & Microgateway actions will all be maintained via a dedicated repo, not under contrib. Enabling the action to be better versioned independently.
• flogo-lib to be renamed to core.

[debovema]

Hi,

Concerning TIBCOSoftware/* repos to be maintained, could it be just a mirroring mechanism from new repos to old ones ?

Concerning new direction for project-flogo/contrib, will it still include the flow-related packages ? Such as the model for instance.

[mellistibco]

Hi @debovema we're thinking that version 0.5.7 will be the last tagged version with new features in TIBCOSoftware/flogo-. We'll then move toward 1.0 which will be in project-flogo/.

As for the project-flogo/contrib, it will not include the flow related packages. Flow related packages will be in a dedicated repository: project-flogo/flows.

What do you think?

[debovema]

That's very clever to separate different concerns from core. I have seen flows, rules, streaming and microgateway in project-flogo org.
I am just a little bit worried about going 1.0.0 just after this (big) refactoring. Maybe a 0.6.x or 0.9.x line would be better before going GA, don't you think ?

[fm-tibco]

@debovema I agree. I think going to 1.0 is a little much. At first we were concerned about it being an incompatible change, but semantic versioning only requires a major version change when a v1 or higher package makes a backwards incompatible change

[mellistibco]

@debovema @fm-tibco good point. Let's go ahead with 0.9.0. We'll have several releases related to 0.9.* to work toward a stable 1.0.0. We'll also do a last call for features and just focus on bugs, etc. If you have any new feature requests, lets get the issues created 😀

[debovema]

OK.

I had a look to all the new repos. The experience is so much smoother :) Especially the Go modules approach, new CLI is hence more responsive too 👌

OK for the last call for features. Don't forget to double merge latest PRs, I have seen one which has not been (TIBCOSoftware/flogo-lib#242) and I didn't find latest listener feature too 🤔

And last, for the semver, any version before 1.0.0 is not GA so it might have breaking changes (even if 0.5.7 -> 0.9.0.is not changing major). So that's not shocking.

[mellistibco]

Awesome, good to hear @debovema! Since we're freezing the current release schedule in the TIBCOSoftware/flogo-* repos (0.5.7 will be the last, unless a major bug is found). We'll start merging in all the features that were added to flogo-lib, contrib, etc into the new project-flogo/* after tagging.