Project cleanup, the path to v2

[GeertJohan]

There are two issues that currently hold back the development of gorp. The first is that there are a lot of issues and PR's open. A lot of PR's need to be rebased or edited before they can be merged in. Secondly: the codebase mostly resides in a single file having about 2200 lines.

To get back on track, we first need to close/merge most issues and PR's. And after that we should divide the source into separate files, clean up the sources, add tests, etc..

The plan

To clean up, we start a plan with 3 phases/steps. Each phase will have a github milestone to assign issues/PR's too. A phase has completed when all issues/PR's in the milestone have been closed/merged.

Phase 1: Cleanup issue/PR backlog (issues, pr's)

• We should merge all bugfix PR's as long as the code is good or needs only small changes to be merged.

Planned to be done 11th july.

Phase 2: Split codebase into separate files (issues, pr's)

• Split code into separate files.
• Create issues about problems we find in the code, set milestone v2-phase3.
• Create issues about in which places code can be improved or cleaned up, set milestone v2-phase3.

Planned to be done 18th july.

Phase 3: Cleanup codebase, add tests, fix bugs (issues, pr's)

• Clean up code.
• Add documentation and specs.
• Add tests.
• Make breaking changes to improve the API. Some will need to be discussed first.
  • Move dialects to their own packages
  • TableMap > Table ?
  • DbMap > DB ?
  • etc..

We are about to release a new major version. At this time we can make breaking changes to the API's to fix naming conventions, etc.

When phase3 starts, there will already be issues with the milestone v2-phase3 addressing the listed tasks.

Phase 3 is the largest phase. This could take anywhere between 5 and 11 weeks. I've placed the due date on 12 september, but it's a rather rough estimate.

Preparation

To prepare for this, I will do the following:

• Add a statement in the README that new PR's except for bugfixes are put on hold because we're cleaning up.
• Set milestone v2-phase1 to feature PR's that can be merged easily, and most bug PR's (even if it needs some work or manual merge).
• Set milestone v2-phase2 to all PR's and issues related to codebase splitting.
• Set milestone v2-phase3 to all PR's and issues related to codebase cleanup, bugs and tests.
• Set milestone v2.1-maybe to all other PR's an issues.
• Close PR's that need way too much work and are unlikely to be merged, even if they're a bugfix. Create a documenting issue for closed bugfix PR's that we can pick up in phase 3.

Completion

When milestone v2-phase3 has been completed we can release v2

• Remove the feature freeze message from the readme.
• Tag the master branch as v2.0.0

When v2 is released, we can start working on new features and performance increments such as prepared statements, etc.

Start

As the phases have been discussed with some of the maintainers of this project, I will start the preparations right away. Feedback is still welcome, we can still modify the plan.

This issue will track global progress and is the best place for discussion about the plan.

[GeertJohan]

I've just assigned all open issues/pr's that are not a question to a milestone as defined above. All preparations are done, v2-phase1 has started.

[GeertJohan]

Phase 1 has been completed! 🍰

[pierreprinetti]

👍 great job

[vinceyuan]

Hello,

Thanks for all efforts on v2. What's the current progress of v2? I see issue #119 (the table name of Postgres should not be converted to lower case) is marked with v2-phase3. So I want to check the progress with you. If #119 is not fixed, will you accept a pull request? (I do see At this time we won't accept new feature-related pull-requests because of changes to the codebase. Please create an issue for your feature and wait until v2.0 has been released. in the README)

Update: I made a pull request 293 to fix this bug. Please take a look.

[aleksandr-vin]

Thanks for your work.
Any progress?

[nelsam]

I think we all hit a bit of a busy time at once, and I'm indecisive. I'll try to break free of that and get some work done on this (at least merge some PRs) soon, though. I should check in on the gitter channel as well as IRC, see if anyone else has been active recently ... but if I can't get a hold of anyone in a short time, I'll just make some decisions.

After all, we can just revert if I pull a dumb.

[djui]

Any progress? What's the current status?

[nelsam]

@djui I finally started on the tests/specs cleanup. It's a pretty small start, but it's something. I've got a presentation to give to some of the people at my work about ORMish libraries; if they decide to use gorp, then I'll have a lot more motivation (and probably time) to work on it. If that's the case, I think we can get through the test cleanup pretty quickly.

There's a pretty big "if" in that statement, but that's just the way life's going for me, lately :)

If things don't go that way, I'll just keep trying to make my days longer.

[djui]

Btw, what's the preferred way of mocking a GORP'd mapped db? Mock the dbMap interface?

[nelsam]

@djui Do you mean mocking a gorp.DbMap in your codebase? I would set up an interface type that contains exactly the methods you're using, then mock out just those methods (either manually or with something like hel or counterfeiter).

But I'm not entirely sure I understand the question correctly.

[djui]

@nelsam Thanks, (yes, I mean gorp.DbMap and sometimes gorp.DbMap.Db) I went with that exact idea.

[hibooboo2]

Has this been finished / sunsetted?

[avitex]

I too would like to know if this library is going to move forward