releases and versions

[David Welton]

Hi,

This is something that I think we ought to do anyway, but this issue
brings it to a head:

https://github.com/epgsql/epgsql/issues/20

My inclination in terms of releases and versioning:

* Tag master right now and call it a release. We should use semantic
versioning, I think. What's that make this, 1.0.0 ?

* Merge devel into master.

* .... work on it ....

* .... 2.0.0 ?

BTW, ideas about handling deprecation / moving the pgsql namespace to
epgsql as per the bug report? Is there really a pressing need for
this or is it just nice to have?

--
David N. Welton

http://www.welton.it/davidw/

http://www.dedasys.com/

[Michael Truog]

The old wg epgsql made it to about 1.4.0 and I am aware of 1.5.0 usage. With all the changes, this code seems like a "2.0.0". When this version gets set, please actually set it within the .app.src file also. Right now it is attempting to depend on the git tag, which then causes problems for the source code, when it gets moved into other situations, or is used by things other than rebar (i.e., it is an annoying practice that isn't supported by Erlang/OTP) (https://github.com/epgsql/epgsql/blob/master/src/epgsql.app.src#L3).

[David Welton]

> The old wg epgsql made it to about 1.4.0 and I am aware of 1.5.0 usage.
> With all the changes, this code seems like a "2.0.0". When this version
> gets set, please actually set it within the .app.src file also. Right now
> it is attempting to depend on the git tag, which then causes problems for
> the source code, when it gets moved into other situations, or is used by
> things other than rebar (i.e., it is an annoying practice that isn't
> supported by Erlang/OTP)
> (https://github.com/epgsql/epgsql/blob/master/src/epgsql.app.src#L3).

Ok, so let's call master 2.0.0. It's fairly tame, so it's a good
starting place. Then we can do 2.1.0 when the devel branch is ready
to go out.