Change module names to match application name

[okeuday]

A historical problem with the wg epgsql driver is that the module names were prefixed with "pgsql" instead of "epgsql". Could we have all modules begin with "epgsql" where the additional interfaces could have a "a" or "i" suffix instead of a prefix, to match the typical Erlang practice of having the Erlang application name be a common prefix for all application module names. This is a small annoyance which would be nice to fix and it doesn't impact any functionality.

[davidw]

Sure, that sounds good to me. What's the most Erlang-ish way to properly transition things? In other words, if someone has their system pegged to 'master' in epgsql, and all of a sudden, the Postgres module no longer works.... that's bad. Sure, they should not have been doing that, but it'd be nice to swap things over gradually.

[okeuday]

If we have a "develop" branch which is pre-release changes and semantic versioning, such changes shouldn't surprise anyone. It would just require a regular release that follows the semantic versioning, to update the master branch gradually.

[okeuday]

@davidw Is this ok?

[davidw]

Ideally, we'd do things like this:

• Make the switch to pgsql, and leave epgsql functioning, but marked 'deprecated', perhaps with some logger warnings or something like that.
• Tag that in a release.
• After N months or a year or whatever, remove epgsql and tag a new release.

Any idea how to best accomplish that?

[okeuday]

We really need it to stay as-is for now and currently the application is named epgsql but the files are pgsql. So, whatever is stable now can be tagged as a release. Whatever is the branch used for development can have the names changed, so that in N months a new release can be tagged.

[davidw]

Errr, I got it backwards in my comment above. In any event, there's one namespace that's getting deprecated, but we shouldn't just switch things out from under people's feet from one moment to the next, is the idea :-)

[okeuday]

Nothing else popped up on the mailing list. Could you tag the master branch at 2.0.0. I can make the changes on a fork to merge into a develop branch.

[davidw]

Sure!

[davidw]

Ok, I have added a 2.0.0 tag.

[okeuday]

Haven't forgotten about this, just need to handle it later in July

[okeuday]

@davidw As part of these changes, can I alter the {vsn, git}, within the .app.src file to be {vsn, "2.0.0"}, since that has been a long-term problem when not using epgsql with rebar (it is a rebar-specific way of using the tag, not valid based on the normal Erlang/OTP .app file values).

[okeuday]

(also when epgsql is not taken from this specific repo, in an ideal world the {vsn, git}, would always work and be dependable, but the world is far from ideal)

[davidw]

Yes, let's use a specific number - I've had troubles with using 'git' elsewhere.

[davidw]

Anything left to do here?

[okeuday]

That should be it. Thanks!

On 07/17/2014 02:41 AM, David N. Welton wrote:

Anything left to do here?

—
Reply to this email directly or view it on GitHub #20 (comment).