What could be the path for following packages?

[sio4]

During the module upgrading, I found some (relatively) new projects are not active and unclear their future plan.

Some packages to be (already) deprecated:

• https://github.com/gobuffalo/gogen --> already archived, the feature moved to genny/gogen.
• https://github.com/gobuffalo/plushgen --> still alive but looks like the feature moved to genny/plushgen.

Feel like the separation could be worth:

• https://github.com/gobuffalo/soda -- is separation WIP? I think the direction could be fine
• https://github.com/gobuffalo/buffalo-cli -- marked as WIP, as v2. Is this project to be the next buffalo cli?
• https://github.com/gobuffalo/plugins -- is it separation of buffalo/plugins and cli/internal/plugins?
• https://github.com/gobuffalo/fizz -- separate package could be ok but how to solve circular dependency with pop?

Direction guideline or design doc required:

• what is the direction of meta/v2? (What is the direction of meta v2? meta#11)
• also what about clara?

[fasmat]

Here my 2 cents to the discussion:

• gobuffalo/soda is behind gobuffalo/pop; imho it should be archived
• gobuffalo/buffalo-cli is outdated and should probably be archived
• gobuffalo/fizz I'm all for integrating it into pop; the cyclic dependency is annoying

[sio4]

For gobuffalo/soda, as far as I remember, the soda command was originally born within the pop package (and now we have its own package for soda) so my guessing is that we tried to make it on a separate/dedicated package. I think the reason could be one or a combination of "making maintenance easy", "making them more pluggable", or related to buffalo-pop package. I wonder if the package soda is just a work-in-progress or the start point of replacement or whatever. So my detailed question about soda is that "what is the purpose and direction of this package".

For buffalo-cli, the naming convention is somewhat strange for me. We use buffalo- prefix for buffalo cli plugins but buffalo-cli doesn't make sense to me. And the project description has WIP mark.

For the fizz, I totally agree that cyclic dependency is a heavy headache. But the reason I told "separate package could be ok but how to solve circular dependency with pop" is that, in my opinion, fizz is a "migration generator" and pop is a kind of "universal database adaptor" or a kind of ORM. They may have different goals, purposes, and should be loosely coupled. So if my understanding is correct and we are on the same page, the direction of discussion could be how to break the dependency chain.

[sio4]

Thank you @paganotoni for giving me one of the URLs of the road to 1.0!

Even though I need to read them very carefully again to understand the thought of @markbates clearer, I read them all with my memory of his tone, :-) and I feel some of his intention about v1.0. Roughly I love the idea, however, I feel like these are too big things for v1 especially without the original initiator.

I am summarizing some key sentences (in my feel) here and will post my thought later.

The series of "Road to 1.0"

• The Road to 1.0: The Beginnings
• The Road to 1.0: Plugins
• The Road to 1.0: Go Modules
• The Road to 1.0: Versioning
• The Road to 1.0: Requiring Modules

My picks:

• Part 1
  • generators are a vital part of getting Buffalo to v1.0.0.
  • Buffalo Generators (and Buffalo) Need to be Extensible
  • One of Buffalo’s goals is to make web development easy in Go for everyone. Right now Buffalo makes that really easy for a couple of situations, but more difficult in others.
  • Eventually, all generators will be rebuilt and moved into plugins.
• Part 2
  • writing a tool to generate Buffalo plugins.
  • I’ve fixed that problem with the https://github.com/gobuffalo/buffalo-plugins plugin.
  • The buffalo/plugins package is being deprecated and has been moved to buffalo-plugins/plugins.
• Part 3
  • making Buffalo 100% compatible with both Go modules
  • github.com/buffalo
  • They will only be moved to the new organization when v1.0.0 release candidates are created.
• Part 4
  • To “manage” this we have been using MINOR as pseudo-MAJOR version and PATCH as pseudo-MINOR.
• Part 5
  • On December 1st, 2019, Buffalo, and all related packages, will no longer support the $GOPATH and will have a minimum Go version of 1.13.