I guess I didn't quite follow the preferred work flow here. I should have started one new branch (in my repo) per bug fix, named appropriately, and PR'd them separately. I'll try to do a better job in the future :)

-Glen

No problem :)
I think this pull request is ready to be merged then.

I'm a little confused on the version numbers I think :(

Shay mentioned using the third digit for patch level. If we go that route,
then bug fixes on 2.0.12 should be 2.0.13, 2.0.14, and so on.

We're scrapping 2.0.13 (which was not going to be just a patch to 2.0.12)
in favor of 2.1.0, but there's already a 2.0.13-beta1 out there. Does that
mean a patch to 2.0.12 now needs to be 2.0.14, instead of 2.0.12.1?

-Glen

On Wed, Dec 4, 2013 at 8:08 AM, Francisco Figueiredo Jr. <
notifications@github.com> wrote:

No problem :)
I think this pull request is ready to be merged then.

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/114#issuecomment-29818403
.

I can understand the confusion :)

As background, try reading http://semver.org, which is a very popular
approach right now, and also adopted by nuget. We don't have to adopt it
(or anything) by the letter, but it's at least a great basis IMHO to think
about versions.

To answer your specific question(s)... in the semver world, as long as we
don't release a 2.1.0, then yes - we go from 2.0.12 to 2.0.13, then to
2.0.14. All these are supposed to fix bugs rather than add features
(although we can relax this a little). Then, when we want to add
(substantial) functionality, we increment the minor version and reset the
patch (so 2.1.0). This is why I proposed that our next release be 2.1.0
rather than 2.0.13 - I think it's a serious functionality improvement, not
just a bugfix version.

What's maybe a bit confusing (I just realized this myself), is that we'd
typically enter a serious beta cycle only when preparing to release a minor
(or major) version. In other words, we'd release 2.1.0-beta1, but typically
not 2.1.1-beta1 (unless there's a good reason to have been test it in the
open first or something). These are the "hotfixes" you see in gitflow (
http://nvie.com/posts/a-successful-git-branching-model/) - no release
branch is created since the hotfix (or patch) release is typically very
light.

PS One think I'm not sure I like with semver is that any API breaking
change requires a new major version. In the real world there's a good
chance you get to major version 42.0.0 pretty quickly.

Am 4 Dec 2013 um 19:35 schrieb Glen Parker notifications@github.com:

I'm a little confused on the version numbers I think :(

Shay mentioned using the third digit for patch level. If we go that route,
then bug fixes on 2.0.12 should be 2.0.13, 2.0.14, and so on.

We're scrapping 2.0.13 (which was not going to be just a patch to 2.0.12)
in favor of 2.1.0, but there's already a 2.0.13-beta1 out there. Does that
mean a patch to 2.0.12 now needs to be 2.0.14, instead of 2.0.12.1?

-Glen

On Wed, Dec 4, 2013 at 8:08 AM, Francisco Figueiredo Jr. <
notifications@github.com> wrote:

No problem :)
I think this pull request is ready to be merged then.

—
Reply to this email directly or view it on GitHub<
https://github.com/npgsql/Npgsql/pull/114#issuecomment-29818403>
.

—
Reply to this email directly or view it on
GitHubhttps://github.com//pull/114#issuecomment-29826663
.

On Wed, Dec 4, 2013 at 10:31 AM, Shay Rojansky notifications@github.comwrote:

I can understand the confusion :)

As background, try reading http://semver.org, which is a very popular
approach right now, and also adopted by nuget. We don't have to adopt it
(or anything) by the letter, but it's at least a great basis IMHO to think
about versions.

To answer your specific question(s)... in the semver world, as long as we
don't release a 2.1.0, then yes - we go from 2.0.12 to 2.0.13, then to
2.0.14. All these are supposed to fix bugs rather than add features
(although we can relax this a little). Then, when we want to add
(substantial) functionality, we increment the minor version and reset the
patch (so 2.1.0). This is why I proposed that our next release be 2.1.0
rather than 2.0.13 - I think it's a serious functionality improvement, not
just a bugfix version.

OK, thanks for clarifying. Makes more sense now.

Although I still think we need to get a patch for 2.0.12 out ASAP, because
that's the fastest way to get a stable release out that can be used with PG
9.3. I agree completely with jumping ahead to 2.1, but that does nothing
to address the rather nasty situation with the latest stable release. 2.1
should get a fairly substantial beta cycle IMO.

Would it be better to release a 2.0.12.1, as kind of a special case? Or go
straight to a more semver-like scheme and call it 2.0.14? Either way, the
code is ready, but the 2.0.12 branch would need to be renamed if we go to
2.0.14.

What's maybe a bit confusing (I just realized this myself), is that we'd
typically enter a serious beta cycle only when preparing to release a
minor
(or major) version. In other words, we'd release 2.1.0-beta1, but
typically
not 2.1.1-beta1 (unless there's a good reason to have been test it in the
open first or something). These are the "hotfixes" you see in gitflow (
http://nvie.com/posts/a-successful-git-branching-model/) - no release
branch is created since the hotfix (or patch) release is typically very
light.

PS One think I'm not sure I like with semver is that any API breaking
change requires a new major version. In the real world there's a good
chance you get to major version 42.0.0 pretty quickly.

I agree, it's a really nice guideline, and like all guidelines, a little
common sense needs to be applied :)

-Glen

On Wed, Dec 4, 2013 at 8:58 PM, Glen Parker notifications@github.comwrote:

On Wed, Dec 4, 2013 at 10:31 AM, Shay Rojansky <notifications@github.com

wrote:

I can understand the confusion :)

As background, try reading http://semver.org, which is a very popular
approach right now, and also adopted by nuget. We don't have to adopt it
(or anything) by the letter, but it's at least a great basis IMHO to
think
about versions.

To answer your specific question(s)... in the semver world, as long as we
don't release a 2.1.0, then yes - we go from 2.0.12 to 2.0.13, then to
2.0.14. All these are supposed to fix bugs rather than add features
(although we can relax this a little). Then, when we want to add
(substantial) functionality, we increment the minor version and reset the
patch (so 2.1.0). This is why I proposed that our next release be 2.1.0
rather than 2.0.13 - I think it's a serious functionality improvement,
not
just a bugfix version.

OK, thanks for clarifying. Makes more sense now.

Although I still think we need to get a patch for 2.0.12 out ASAP, because
that's the fastest way to get a stable release out that can be used with PG
9.3. I agree completely with jumping ahead to 2.1, but that does nothing
to address the rather nasty situation with the latest stable release. 2.1
should get a fairly substantial beta cycle IMO.

Would it be better to release a 2.0.12.1, as kind of a special case? Or go
straight to a more semver-like scheme and call it 2.0.14? Either way, the
code is ready, but the 2.0.12 branch would need to be renamed if we go to
2.0.14.

Sure, you definitely have a point. When the discussion started I was under
the impression 2.1.0 would be released pretty quickly, but I definitely
think I was underestimating things.

It makes perfect sense to release a bugfix because of the 9.3 situation,
and there's nothing stopping us from calling it 2.0.13 either (unless I'm
missing something?). The beta has been out, we think it's stable, it can
practically be pushed out as is by removing the -beta. Then we can quietly
handle the 2.1 release as you propose.

What's maybe a bit confusing (I just realized this myself), is that we'd
typically enter a serious beta cycle only when preparing to release a
minor
(or major) version. In other words, we'd release 2.1.0-beta1, but
typically
not 2.1.1-beta1 (unless there's a good reason to have been test it in the
open first or something). These are the "hotfixes" you see in gitflow (
http://nvie.com/posts/a-successful-git-branching-model/) - no release
branch is created since the hotfix (or patch) release is typically very
light.

PS One think I'm not sure I like with semver is that any API breaking
change requires a new major version. In the real world there's a good
chance you get to major version 42.0.0 pretty quickly.

I agree, it's a really nice guideline, and like all guidelines, a little
common sense needs to be applied :)

Yep :)

-Glen

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/114#issuecomment-29833776
.

Although I still think we need to get a patch for 2.0.12 out ASAP,
because
that's the fastest way to get a stable release out that can be used with
PG
9.3. I agree completely with jumping ahead to 2.1, but that does nothing
to address the rather nasty situation with the latest stable release.
2.1
should get a fairly substantial beta cycle IMO.

Would it be better to release a 2.0.12.1, as kind of a special case? Or
go
straight to a more semver-like scheme and call it 2.0.14? Either way,
the
code is ready, but the 2.0.12 branch would need to be renamed if we go
to
2.0.14.

Sure, you definitely have a point. When the discussion started I was under
the impression 2.1.0 would be released pretty quickly, but I definitely
think I was underestimating things.

It makes perfect sense to release a bugfix because of the 9.3 situation,
and there's nothing stopping us from calling it 2.0.13 either (unless I'm
missing something?). The beta has been out, we think it's stable, it can
practically be pushed out as is by removing the -beta. Then we can quietly
handle the 2.1 release as you propose.

Well I branched from 2.0.12. If we call that 2.0.13, then 2.0.13 will not
be a child of 2.0.13-beta1, which is really misleading.

So you're saying to abandon 2.0.12 and branch at the v2.0.13-beta1 tag,
call it 2.0.13, toss in the critical NpgsqlError fix, and release as 2.0.13
stable? I was shying away from that, because 2.0.12 is considered stable
and is in use, while 2.0.13-beta is presumably in very limited use, since
it's still a beta.

I'll branch at 2.0.13, fix it, and we can test it out :)

-Glen

I'll branch at 2.0.13, fix it, and we can test it out :)

And there it is.

-Glen

On Wed, Dec 4, 2013 at 9:21 PM, Glen Parker notifications@github.comwrote:

Although I still think we need to get a patch for 2.0.12 out ASAP,
because
that's the fastest way to get a stable release out that can be used
with
PG
9.3. I agree completely with jumping ahead to 2.1, but that does
nothing
to address the rather nasty situation with the latest stable release.
2.1
should get a fairly substantial beta cycle IMO.

Would it be better to release a 2.0.12.1, as kind of a special case? Or
go
straight to a more semver-like scheme and call it 2.0.14? Either way,
the
code is ready, but the 2.0.12 branch would need to be renamed if we go
to
2.0.14.

Sure, you definitely have a point. When the discussion started I was
under
the impression 2.1.0 would be released pretty quickly, but I definitely
think I was underestimating things.

It makes perfect sense to release a bugfix because of the 9.3 situation,
and there's nothing stopping us from calling it 2.0.13 either (unless I'm
missing something?). The beta has been out, we think it's stable, it can
practically be pushed out as is by removing the -beta. Then we can
quietly
handle the 2.1 release as you propose.

Well I branched from 2.0.12. If we call that 2.0.13, then 2.0.13 will not
be a child of 2.0.13-beta1, which is really misleading.

Just looked at the state of things in git a little. I think I misunderstood
the whole situation before... :)

If I understand correctly, on June 27 we tagged the master as 2.0.13-beta1
(commit 8374f60) and haven't done anything
on a 2.0.13 release since, right? Right now we want to release an
as-light-as-possible release to help with outstanding bugs, and then focus
our attention on 2.1.0.

Since 2.0.13-beta1 isn't light at all (many changes since 2.0.12,
relatively untested), you're proposing taking 2.0.12 and simply applying
the NpgsqlError fix on top of it - that makes perfect sense to me. Then,
since we already "released" a 2.0.13-beta1 and don't want to confuse
people, it would make sense to skip a minor version and release 2.0.14.

I say go for it :) You don't even need to create a branch, just checkout
2.0.12, apply your fix, bump the version strings and tag as 2.0.14. Create
the nuget and publish away...

Am I finally understanding everything?

So you're saying to abandon 2.0.12 and branch at the v2.0.13-beta1 tag,

call it 2.0.13, toss in the critical NpgsqlError fix, and release as 2.0.13
stable? I was shying away from that, because 2.0.12 is considered stable
and is in use, while 2.0.13-beta is presumably in very limited use, since
it's still a beta.

I'll branch at 2.0.13, fix it, and we can test it out :)

-Glen

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/114#issuecomment-29836017
.

On Wed, Dec 4, 2013 at 11:40 AM, Shay Rojansky notifications@github.comwrote:

On Wed, Dec 4, 2013 at 9:21 PM, Glen Parker notifications@github.comwrote:

Although I still think we need to get a patch for 2.0.12 out ASAP,
because
that's the fastest way to get a stable release out that can be used
with
PG
9.3. I agree completely with jumping ahead to 2.1, but that does
nothing
to address the rather nasty situation with the latest stable
release.
2.1
should get a fairly substantial beta cycle IMO.

Would it be better to release a 2.0.12.1, as kind of a special case?
Or
go
straight to a more semver-like scheme and call it 2.0.14? Either
way,
the
code is ready, but the 2.0.12 branch would need to be renamed if we
go
to
2.0.14.

Sure, you definitely have a point. When the discussion started I was
under
the impression 2.1.0 would be released pretty quickly, but I
definitely
think I was underestimating things.

It makes perfect sense to release a bugfix because of the 9.3
situation,
and there's nothing stopping us from calling it 2.0.13 either (unless
I'm
missing something?). The beta has been out, we think it's stable, it
can
practically be pushed out as is by removing the -beta. Then we can
quietly
handle the 2.1 release as you propose.

Well I branched from 2.0.12. If we call that 2.0.13, then 2.0.13 will
not
be a child of 2.0.13-beta1, which is really misleading.

Just looked at the state of things in git a little. I think I
misunderstood
the whole situation before... :)

If I understand correctly, on June 27 we tagged the master as 2.0.13-beta1
(commit 8374f60) and haven't done
anything
on a 2.0.13 release since, right? Right now we want to release an
as-light-as-possible release to help with outstanding bugs, and then focus
our attention on 2.1.0.

Since 2.0.13-beta1 isn't light at all (many changes since 2.0.12,
relatively untested), you're proposing taking 2.0.12 and simply applying
the NpgsqlError fix on top of it - that makes perfect sense to me. Then,
since we already "released" a 2.0.13-beta1 and don't want to confuse
people, it would make sense to skip a minor version and release 2.0.14.

I say go for it :) You don't even need to create a branch, just checkout
2.0.12, apply your fix, bump the version strings and tag as 2.0.14. Create
the nuget and publish away...

Am I finally understanding everything?

Yep, sound like you've got it :)

So, 2.0.12 and 2.0.13 are branched and fixed now. If we jump 2.0.12 to
2.0.14, then we can just delete the 2.0.13 branch and forget all about it.

But that's about where I jump off the bus; I have no idea how to go about
putting together a release.

-Glen

@franciscojunior, I hope we didn't drive you crazy here :)

Glen thinks (and I agree after finally understanding the whole situation) that we should quickly release a 2.0.14 version, which is basically 2.0.12 + the urgent NpgsqlError bug that's causing people a lot of trouble. Then, we can calmly prepare the 2.1.0 release (@glenebob, I don't see the 2.0.14 tag yet, can you create it in npgsql/npgsql?

Do you agree that this is a good idea? If so, can you do the release with the current manual nuget flow (for 2.1.0 we can use the build server and everything).

On Wed, Dec 4, 2013 at 11:55 AM, Shay Rojansky notifications@github.comwrote:

@franciscojunior https://github.com/franciscojunior, I hope we didn't
drive you crazy here :)

Glen thinks (and I agree after finally understanding the whole situation)
that we should quickly release a 2.0.14 version, which is basically 2.0.12

• the urgent NpgsqlError bug that's causing people a lot of trouble. Then,
  we can calmly prepare the 2.1.0 release (@glenebobhttps://github.com/glenebob,
  I don't the 2.0.14 tag yet, can you create it in npgsql/npgsql?

OK, I updated the release files in the 2.0.12 branch and tagged v2.0.14.
Hopefully I didn't screw it up too bad :)

-Glen

Do you agree that this is a good idea? If so, can you do the release with
the current manual nuget flow (for 2.1.0 we can use the build server and
everything).

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/114#issuecomment-29839169
.

I say +1 for it.

I know users will get a little bit confused by the fact that a 2.0.14 has
fewer features as 2.0.13-beta1 but we can explain that 2.0.13 was promoted
to be 2.1 and that 2.0.14 is a replace for 2.0.12 with fixes for PostgreSQL
9.3 support.

About the release process, Glen, we need to create zip files with versions
for .net 2.0, 3.5, 4.0 and 4.5 with ef support. Those zips are created by
Josh Cooley and I created the mono zip files as well as the nuget package.
Glen, Shay, would you like to participate in the creation of the release
packages? I think it would be a very good experience.
Em 04/12/2013 19:08, "Glen Parker" notifications@github.com escreveu:

On Wed, Dec 4, 2013 at 11:55 AM, Shay Rojansky notifications@github.comwrote:

@franciscojunior https://github.com/franciscojunior, I hope we didn't
drive you crazy here :)

Glen thinks (and I agree after finally understanding the whole
situation)
that we should quickly release a 2.0.14 version, which is basically
2.0.12

• the urgent NpgsqlError bug that's causing people a lot of trouble.
  Then,
  we can calmly prepare the 2.1.0 release (@glenebob<
  https://github.com/glenebob>,
  I don't the 2.0.14 tag yet, can you create it in npgsql/npgsql?

OK, I updated the release files in the 2.0.12 branch and tagged v2.0.14.
Hopefully I didn't screw it up too bad :)

-Glen

Do you agree that this is a good idea? If so, can you do the release
with
the current manual nuget flow (for 2.1.0 we can use the build server and
everything).

—
Reply to this email directly or view it on GitHub<
https://github.com/npgsql/Npgsql/pull/114#issuecomment-29839169>
.

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/114#issuecomment-29845662
.

On Wed, Dec 4, 2013 at 5:53 PM, Francisco Figueiredo Jr. <
notifications@github.com> wrote:

I say +1 for it.

I know users will get a little bit confused by the fact that a 2.0.14 has
fewer features as 2.0.13-beta1 but we can explain that 2.0.13 was promoted
to be 2.1 and that 2.0.14 is a replace for 2.0.12 with fixes for
PostgreSQL
9.3 support.

About the release process, Glen, we need to create zip files with versions
for .net 2.0, 3.5, 4.0 and 4.5 with ef support. Those zips are created by
Josh Cooley and I created the mono zip files as well as the nuget package.
Glen, Shay, would you like to participate in the creation of the release
packages? I think it would be a very good experience.

Sure, count me in!

Now that the build server is up and running, will it be useful for this old
branch?

-Glen

2.0.14 doesn't include many changes I did to make the build server process work /be streamlined...

My suggestion is that since you want 2.0.14 out as fast as possible, just go ahead and create the packages the old way. We'll start using the build server for 2.1.0...

That's what I figured. I played around a bit earlier tonight and ran into
lots of issues. Building public projects for release on Windows is never
the easy street that it usually is on *nix. I'll get back into it
tomorrow. Hopefully Francisco has a tip or two for me.

-Glen

On Wed, Dec 4, 2013 at 10:34 PM, Shay Rojansky notifications@github.comwrote:

2.0.14 doesn't include many changes I did to make the build server process
work /be streamlined...

My suggestion is that since you want 2.0.14 out as fast as possible, just
go ahead and create the packages the old way. We'll start using the build
server for 2.1.0...

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/114#issuecomment-29874740
.

Which problems did you get, Glen?

On Thu, Dec 5, 2013 at 4:56 AM, Glen Parker notifications@github.comwrote:

That's what I figured. I played around a bit earlier tonight and ran into
lots of issues. Building public projects for release on Windows is never
the easy street that it usually is on *nix. I'll get back into it
tomorrow. Hopefully Francisco has a tip or two for me.

-Glen

On Wed, Dec 4, 2013 at 10:34 PM, Shay Rojansky notifications@github.comwrote:

2.0.14 doesn't include many changes I did to make the build server
process
work /be streamlined...

My suggestion is that since you want 2.0.14 out as fast as possible,
just
go ahead and create the packages the old way. We'll start using the
build
server for 2.1.0...

—
Reply to this email directly or view it on GitHub<
https://github.com/npgsql/Npgsql/pull/114#issuecomment-29874740>
.

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/114#issuecomment-29875441
.

Regards,

Francisco Figueiredo Jr.
Npgsql Lead Developer
http://www.npgsql.org
http://gplus.to/franciscojunior
http://fxjr.blogspot.com
http://twitter.com/franciscojunior

The build scripts don't work. Build.bat says no .net SDK installed, which
seems weird, when I have 4 different versions of VS on this machine. The
policyFileBuild script says 'al' command not found. Same problem I assume.

What exactly is the "normal" procedure for building Npgsql for release?

-Glen

On Thu, Dec 5, 2013 at 3:22 AM, Francisco Figueiredo Jr. <
notifications@github.com> wrote:

Which problems did you get, Glen?

On Thu, Dec 5, 2013 at 4:56 AM, Glen Parker notifications@github.comwrote:

That's what I figured. I played around a bit earlier tonight and ran
into
lots of issues. Building public projects for release on Windows is never
the easy street that it usually is on *nix. I'll get back into it
tomorrow. Hopefully Francisco has a tip or two for me.

-Glen

On Wed, Dec 4, 2013 at 10:34 PM, Shay Rojansky notifications@github.comwrote:

2.0.14 doesn't include many changes I did to make the build server
process
work /be streamlined...

My suggestion is that since you want 2.0.14 out as fast as possible,
just
go ahead and create the packages the old way. We'll start using the
build
server for 2.1.0...

—
Reply to this email directly or view it on GitHub<
https://github.com/npgsql/Npgsql/pull/114#issuecomment-29874740>
.

—
Reply to this email directly or view it on GitHub<
https://github.com/npgsql/Npgsql/pull/114#issuecomment-29875441>
.

Regards,

Francisco Figueiredo Jr.
Npgsql Lead Developer
http://www.npgsql.org
http://gplus.to/franciscojunior
http://fxjr.blogspot.com
http://twitter.com/franciscojunior

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/114#issuecomment-29889991
.

he build scripts don't work. Build.bat says no .net SDK installed, which
seems weird, when I have 4 different versions of VS on this machine. The
policyFileBuild script says 'al' command not found. Same problem I assume.

Build would call nant to create the Npgsql.dll file. But I think Josh Cooley didn't use the build.bat file. I think he used vs.net directly to create the assemblies. I just sent him a mail talking about this discussion and asking him how he created the windows packages.

The policyFileBuild script has to be run in the vs.net command prompt. This is because vs.net command prompt sets some env variables which the script uses.

What exactly is the "normal" procedure for building Npgsql for release?

1. I created the download release package in the pgfoundry.org
2. I updated the release notes and changelog files in pgfoundry
3. Josh Cooley created the zip files packages version for windows .net and source
4. I created the zip files packages version for Mono
5. We uploaded the files to pgfoundry site.
6. We made the release package in pgfoundry download area visible

I also asked Josh which day would be better for him to participate in the creation of the 2.0.14 release. He said that Saturday, Sunday or Monday after 8 pm is ok. Or Tuesday or Thursday next week.
Which day would be better for you?

Guys, I suggest that for 2.0.14 you do it in "quick and dirty"mode :) This is probably the last release we'll be doing without the new build system, build server, etc. which will make all this much much easier.

Also, don't forget to make a nuget package - I think this is how most people nowadays use npgsql. You can take the nuspec from the master and modify it accordingly, and then run nuget -pack on it.

If you want/need help from me with any of this let me know.

Yes, I did the builds in visual studio. I probably should have created an
msbuild script that did it, but I never got around to doing that. It was
easy enough to flip the project settings and build the various release
builds. Once i created a release build, I renamed the target directory,
put the publisher policy file in there and zipped it up.

On Fri, Dec 6, 2013 at 5:20 AM, Francisco Figueiredo Jr. <
notifications@github.com> wrote:

he build scripts don't work. Build.bat says no .net SDK installed, which
seems weird, when I have 4 different versions of VS on this machine. The
policyFileBuild script says 'al' command not found. Same problem I assume.

Build would call nant to create the Npgsql.dll file. But I think Josh
Cooley didn't use the build.bat file. I think he used vs.net directly to
create the assemblies. I just sent him a mail talking about this discussion
and asking him how he created the windows packages.

The policyFileBuild script has to be run in the vs.net command prompt.
This is because vs.net command prompt sets some env variables which the
script uses.

What exactly is the "normal" procedure for building Npgsql for release?

1. I created the download release package in the pgfoundry.org
2. I updated the release notes and changelog files in pgfoundry
3. Josh Cooley created the zip files packages version for windows .net
   and source
4. I created the zip files packages version for Mono
5. We uploaded the files to pgfoundry site.
6. We made the release package in pgfoundry download area visible

I also asked Josh which day would be better for him to participate in the
creation of the 2.0.14 release. He said that Saturday, Sunday or Monday
after 8 pm is ok. Or Tuesday or Thursday next week.
Which day would be better for you?

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/114#issuecomment-29981341
.

@jbcooley, I just noticed npgsql has a publisher policy. I'm not super-familiar with this feature, and wanted to understand a bit more...

• Is it a good idea to always force users to use the latest (installed) version of npgsql? We're preventing them from a side-by-side use of an older and newer version for testing purposes, etc.
• The publisher policy DLL needs to be installed in the GAC in order to have an effect, right? So if the user already has to do manual GAC management with gacutil, why not just let them choose exactly which versions they want (i.e. without publisher policy etc.)

Basically I haven't seen this in other open source projects and am trying to understand the idea. If we keep it I'll integrate it into our new build process too...

I think we started to use this policy file because we had some reports of users who installed a newer version and had their applications not working anymore. This was because they were compiling the app against an specific Npgsql version and after the update the linking couldn't be satisfied anymore.

Hmm, ok. I don't really know so much about these "redirection" mechanisms.

I think maybe this should in general be more under the control of the user, and not via a "publisher-pushed" policy. Users can do many things, they can:

• If the use npgsql in their project dir (not GAC), usually via nuget, then it's up to them to get the version they want and distribute it
• If an application references an old npgsql and a user wants to override that, they can override this with assembly redirects in their App.config file

Basically this seems to be more of a user-side problem, which we shouldn't interfere with (using something like publisher policies). But I'm really not very sure, can someone else give their opinion?

The two other providers I'm familiar with using (for SQL Server, and
Oracle) have ways of updating the client in a global way. One way is to
publish updates without changing the assembly version number, the other is
to publish a policy file that indicates you haven't made breaking changes.

There are two ways to deploy Npgsql. One way is to deploy it to the GAC
and we publish a policy file that is a promise that we haven't broken
compatibility. The publisher policy file is optional, so they don't have
to accept it. The other way is to deploy in the bin directory with the
application. This second way is becoming very popular, but there are many
developers and administrators that prefer the former.

One scenario where the publisher policy file can be extremely useful is
where the database is upgraded, and the client gets updated to support this
new version of the database (see our recent fixes for supporting 9.3).
This can be done with no impact to the application provided that we
preserve backward compatibility.

Ultimately, I believe my stance is very close to yours. We shouldn't
interfere with the user. I just want to provide them this option.

On Fri, Dec 6, 2013 at 12:20 PM, Shay Rojansky notifications@github.comwrote:

Hmm, ok. I don't really know so much about these "redirection" mechanisms.

I think maybe this should in general be more under the control of the
user, and not via a "publisher-pushed" policy. Users can do many things,
they can:

• If the use npgsql in their project dir (not GAC), usually via nuget,
  then it's up to them to get the version they want and distribute it
• If an application references an old npgsql and a user wants to
  override that, they can override this with assembly redirects in their
  App.config file

Basically this seems to be more of a user-side problem, which we
shouldn't interfere with (using something like publisher policies). But I'm
really not very sure, can someone else give their opinion?

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/114#issuecomment-30016497
.

OK guys,

I think I have the binary and source .zip files ready to go.

I added VS2012 files to git and used them to do the builds. I've got
Net-2.0, Net-3.5+EF, and Net-4.0+EF. There's no Net-4.5 binaries for
2.0.12, so I didn't do one either.

I have no idea how to generate the api-docs, or the nuget package.

Francisco, if you want to me to upload the files directly to pg-foundry,
you'll have to let me in on the project there. My user name there is
glenebob (bet you didn't see that coming). But, I think you and/or Josh
should check them over first. Let me know how you'd like me to get them to
you.

-Glen

On Fri, Dec 6, 2013 at 11:21 AM, jbcooley notifications@github.com wrote:

The two other providers I'm familiar with using (for SQL Server, and
Oracle) have ways of updating the client in a global way. One way is to
publish updates without changing the assembly version number, the other is
to publish a policy file that indicates you haven't made breaking changes.

There are two ways to deploy Npgsql. One way is to deploy it to the GAC
and we publish a policy file that is a promise that we haven't broken
compatibility. The publisher policy file is optional, so they don't have
to accept it. The other way is to deploy in the bin directory with the
application. This second way is becoming very popular, but there are many
developers and administrators that prefer the former.

One scenario where the publisher policy file can be extremely useful is
where the database is upgraded, and the client gets updated to support
this
new version of the database (see our recent fixes for supporting 9.3).
This can be done with no impact to the application provided that we
preserve backward compatibility.

Ultimately, I believe my stance is very close to yours. We shouldn't
interfere with the user. I just want to provide them this option.

On Fri, Dec 6, 2013 at 12:20 PM, Shay Rojansky notifications@github.comwrote:

Hmm, ok. I don't really know so much about these "redirection"
mechanisms.

I think maybe this should in general be more under the control of the
user, and not via a "publisher-pushed" policy. Users can do many things,
they can:

• If the use npgsql in their project dir (not GAC), usually via nuget,
  then it's up to them to get the version they want and distribute it
• If an application references an old npgsql and a user wants to
  override that, they can override this with assembly redirects in their
  App.config file

Basically this seems to be more of a user-side problem, which we
shouldn't interfere with (using something like publisher policies). But
I'm
really not very sure, can someone else give their opinion?

—
Reply to this email directly or view it on GitHub<
https://github.com/npgsql/Npgsql/pull/114#issuecomment-30016497>
.

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/114#issuecomment-30021319
.

On Fri, Dec 6, 2013 at 7:52 AM, jbcooley notifications@github.com wrote:

Yes, I did the builds in visual studio.

That's what I did. I've been having trouble with VS though. When I click
the framework version target drop down list, it gets part way through the
re-config and stops, refusing to show anything but version 4. But, after a
bunch of screwing around, it appears to actually compile against the
version you requested. That's why it took so long. It's kind of confusing
to verify what framework an assembly was compiled against.

-Glen

On Fri, Dec 6, 2013 at 3:20 AM, Francisco Figueiredo Jr. <
notifications@github.com> wrote:

I also asked Josh which day would be better for him to participate in the
creation of the 2.0.14 release. He said that Saturday, Sunday or Monday
after 8 pm is ok. Or Tuesday or Thursday next week.

Which day would be better for you?

I should be available any of those days/times except Thursday, depending on
what "8 PM" means. What's the timezone? I don't know where Josh is.

-Glen

@glenebob, for the nuget package look at this as an example: https://github.com/npgsql/Npgsql/blob/master/Npgsql/Npgsql.nuspec

It just needs to point to the actual DLLs (and possibly xmls) you want to package. No need for the .pdb and .cs files (as you won't be building a symbol/debug nuget).

Don't forget to update the version though.

XML documentation can be generated with the compiler's /doc: feature: http://msdn.microsoft.com/en-us/library/3260k4x7.aspx

@jbcooley, regarding the publisher policy, I see what you mean.

The whole discussion seems to be a part of the mode where users install npgsql into their GAC (publisher policies don't make any sense otherwise, right?). This seems to be an installation flow that's completely separate from nuget. It seems to make sense to continue to distribute a zip for those cases, which would contain the publisher policy (which the user can choose to install into the GAC or not).

One additional thing to think about - it seems we're leaning towards more semver-like versioning. This might mean we do publisher policies only within the same minor version, but not across minor versions. In other words, publisher policies would specify equivalence from 2.0.x to the latest 2.0 version (i.e. 2.0.14), but not to 2.1. This is since 2.0->2.1 represents a much heavier upgrade which is a less likely to be 100% smooth. Does that sound right?

In any case, I'll start looking at automating the zip packaging on the build server for 2.1.0 and on.

The XML documentation isn't the issue - it's getting generated just fine.

What I'm referring to is the html apidocs as found here...
http://pgfoundry.org/frs/download.php/3351/Npgsql2.0.12-apidocs-html.zip

-Glen

On Fri, Dec 6, 2013 at 1:53 PM, Shay Rojansky notifications@github.comwrote:

XML documentation can be generated with the compiler's /doc: feature:
http://msdn.microsoft.com/en-us/library/3260k4x7.aspx

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/114#issuecomment-30032754
.

I used nant to generate the com. I think it can also generate the html docs.

Josh

On Dec 6, 2013, at 7:27 PM, Glen Parker notifications@github.com wrote:

The XML documentation isn't the issue - it's getting generated just fine.

What I'm referring to is the html apidocs as found here...
http://pgfoundry.org/frs/download.php/3351/Npgsql2.0.12-apidocs-html.zip

-Glen

On Fri, Dec 6, 2013 at 1:53 PM, Shay Rojansky notifications@github.comwrote:

XML documentation can be generated with the compiler's /doc: feature:
http://msdn.microsoft.com/en-us/library/3260k4x7.aspx

—
Reply to this email directly or view it on GitHub<
https://github.com/npgsql/Npgsql/pull/114#issuecomment-30032754>
.

—
Reply to this email directly or view it on
GitHubhttps://github.com//pull/114#issuecomment-30043907
.

I that sounds right. I know there's been discussion on dropping v2
protocol, and that definitely would warrant a change in the publisher
policy.

Josh

On Dec 6, 2013, at 4:31 PM, Shay Rojansky notifications@github.com wrote:

@jbcooley https://github.com/jbcooley, regarding the publisher policy, I
see what you mean.

The whole discussion seems to be a part of the mode where users install
npgsql into their GAC (publisher policies don't make any sense otherwise,
right?). This seems to be an installation flow that's completely separate
from nuget. It seems to make sense to continue to distribute a zip for
those cases, which would contain the publisher policy (which the user can
choose to install into the GAC or not).

One additional thing to think about - it seems we're leaning towards more
semver http://semver.org-like versioning. This might mean we do publisher
policies only within the same minor version, but not across minor versions.
In other words, publisher policies would specify equivalence from 2.0.x to
the latest 2.0 version (i.e. 2.0.14), but not to 2.1. This is since
2.0->2.1 represents a much heavier upgrade which is a less likely to be
100% smooth. Does that sound right?

In any case, I'll start looking at automating the zip packaging on the
build server for 2.1.0 and on.

—
Reply to this email directly or view it on
GitHubhttps://github.com//pull/114#issuecomment-30035318
.

Em 06/12/2013 23:27, "Glen Parker" notifications@github.com escreveu:

The XML documentation isn't the issue - it's getting generated just fine.

What I'm referring to is the html apidocs as found here...
http://pgfoundry.org/frs/download.php/3351/Npgsql2.0.12-apidocs-html.zip

Those are created with ./build.sh apidocs ( or build.bat if you are running
on Windows)

I create those when creating the mono release.

-Glen

On Fri, Dec 6, 2013 at 1:53 PM, Shay Rojansky notifications@github.comwrote:

XML documentation can be generated with the compiler's /doc: feature:
http://msdn.microsoft.com/en-us/library/3260k4x7.aspx

—
Reply to this email directly or view it on GitHub<
https://github.com/npgsql/Npgsql/pull/114#issuecomment-30032754>
.

—
Reply to this email directly or view it on GitHub.

Em 06/12/2013 19:20, "Glen Parker" notifications@github.com escreveu:

OK guys,

I think I have the binary and source .zip files ready to go.

I added VS2012 files to git and used them to do the builds. I've got
Net-2.0, Net-3.5+EF, and Net-4.0+EF. There's no Net-4.5 binaries for
2.0.12, so I didn't do one either.

Excellent, Glen!
Although there is no net-4.5 binaries for 2.0.12, I think it would be
worthwhile to create for 2.0.14. I remember I received some reports about
users wanting to use a .net-4.5 only setup but had to install a previous
net version in order to run Npgsql. I think a net45 version would be very
helpful for those cases.

I have no idea how to generate the api-docs, or the nuget package.

Francisco, if you want to me to upload the files directly to pg-foundry,
you'll have to let me in on the project there. My user name there is
glenebob (bet you didn't see that coming).

Sure! I'll add your name to the project. About your username, how did you
know I didn't see that coming? ;-)

But, I think you and/or Josh
should check them over first. Let me know how you'd like me to get them
to
you.

Sure. I'd like to check with you if we could try to make the release
tonight? Josh said it was OK for him tonight after 8pm. Local time. My
current time zone is gmt - 2.

I think we all can check if everything is OK and make the release.

What do you think?

-Glen

On Fri, Dec 6, 2013 at 11:21 AM, jbcooley notifications@github.com
wrote:

The two other providers I'm familiar with using (for SQL Server, and
Oracle) have ways of updating the client in a global way. One way is to
publish updates without changing the assembly version number, the other
is
to publish a policy file that indicates you haven't made breaking
changes.

There are two ways to deploy Npgsql. One way is to deploy it to the GAC
and we publish a policy file that is a promise that we haven't broken
compatibility. The publisher policy file is optional, so they don't
have
to accept it. The other way is to deploy in the bin directory with the
application. This second way is becoming very popular, but there are
many
developers and administrators that prefer the former.

One scenario where the publisher policy file can be extremely useful is
where the database is upgraded, and the client gets updated to support
this
new version of the database (see our recent fixes for supporting 9.3).
This can be done with no impact to the application provided that we
preserve backward compatibility.

Ultimately, I believe my stance is very close to yours. We shouldn't
interfere with the user. I just want to provide them this option.

On Fri, Dec 6, 2013 at 12:20 PM, Shay Rojansky notifications@github.comwrote:

Hmm, ok. I don't really know so much about these "redirection"
mechanisms.

I think maybe this should in general be more under the control of the
user, and not via a "publisher-pushed" policy. Users can do many
things,
they can:

• If the use npgsql in their project dir (not GAC), usually via
  nuget,
  then it's up to them to get the version they want and distribute it
• If an application references an old npgsql and a user wants to
  override that, they can override this with assembly redirects in
  their
  App.config file

Basically this seems to be more of a user-side problem, which we
shouldn't interfere with (using something like publisher policies).
But
I'm
really not very sure, can someone else give their opinion?

—
Reply to this email directly or view it on GitHub<
https://github.com/npgsql/Npgsql/pull/114#issuecomment-30016497>
.

—
Reply to this email directly or view it on GitHub<
https://github.com/npgsql/Npgsql/pull/114#issuecomment-30021319>
.

—
Reply to this email directly or view it on GitHub.

Em 06/12/2013 19:27, "Glen Parker" notifications@github.com escreveu:

On Fri, Dec 6, 2013 at 3:20 AM, Francisco Figueiredo Jr. <
notifications@github.com> wrote:

I also asked Josh which day would be better for him to participate in
the
creation of the 2.0.14 release. He said that Saturday, Sunday or Monday
after 8 pm is ok. Or Tuesday or Thursday next week.

Which day would be better for you?

I should be available any of those days/times except Thursday, depending
on
what "8 PM" means. What's the timezone? I don't know where Josh is.

Great! So I think a release tonight may be possible.

He is also from USA. His time zone is gmt - 6.

There is no problem if something comes up and we can't meet to make the
release (this happened before).

I also think we can make the release asynchronously. Once the reason can be
kept hidden in pgfoundry, we can check the files and upload them to
pgfoundry. When everything is ready we make the visibility switch.

-Glen

—
Reply to this email directly or view it on GitHub.

Glen, when I tried to add you to pgfoundry, the system said the user name
couldn't be found.
:-(
Em 06/12/2013 19:20, "Glen Parker" notifications@github.com escreveu:

OK guys,

I think I have the binary and source .zip files ready to go.

I added VS2012 files to git and used them to do the builds. I've got
Net-2.0, Net-3.5+EF, and Net-4.0+EF. There's no Net-4.5 binaries for
2.0.12, so I didn't do one either.

I have no idea how to generate the api-docs, or the nuget package.

Francisco, if you want to me to upload the files directly to pg-foundry,
you'll have to let me in on the project there. My user name there is
glenebob (bet you didn't see that coming). But, I think you and/or Josh
should check them over first. Let me know how you'd like me to get them to
you.

-Glen

On Fri, Dec 6, 2013 at 11:21 AM, jbcooley notifications@github.com
wrote:

The two other providers I'm familiar with using (for SQL Server, and
Oracle) have ways of updating the client in a global way. One way is to
publish updates without changing the assembly version number, the other
is
to publish a policy file that indicates you haven't made breaking
changes.

There are two ways to deploy Npgsql. One way is to deploy it to the GAC
and we publish a policy file that is a promise that we haven't broken
compatibility. The publisher policy file is optional, so they don't have
to accept it. The other way is to deploy in the bin directory with the
application. This second way is becoming very popular, but there are
many
developers and administrators that prefer the former.

One scenario where the publisher policy file can be extremely useful is
where the database is upgraded, and the client gets updated to support
this
new version of the database (see our recent fixes for supporting 9.3).
This can be done with no impact to the application provided that we
preserve backward compatibility.

Ultimately, I believe my stance is very close to yours. We shouldn't
interfere with the user. I just want to provide them this option.

On Fri, Dec 6, 2013 at 12:20 PM, Shay Rojansky notifications@github.comwrote:

Hmm, ok. I don't really know so much about these "redirection"
mechanisms.

I think maybe this should in general be more under the control of the
user, and not via a "publisher-pushed" policy. Users can do many
things,
they can:

• If the use npgsql in their project dir (not GAC), usually via nuget,
  then it's up to them to get the version they want and distribute it
• If an application references an old npgsql and a user wants to
  override that, they can override this with assembly redirects in their
  App.config file

Basically this seems to be more of a user-side problem, which we
shouldn't interfere with (using something like publisher policies).
But
I'm
really not very sure, can someone else give their opinion?

—
Reply to this email directly or view it on GitHub<
https://github.com/npgsql/Npgsql/pull/114#issuecomment-30016497>
.

—
Reply to this email directly or view it on GitHub<
https://github.com/npgsql/Npgsql/pull/114#issuecomment-30021319>
.

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/114#issuecomment-30030362
.

On Sat, Dec 7, 2013 at 2:51 AM, Francisco Figueiredo Jr. <
notifications@github.com> wrote:

Em 06/12/2013 19:20, "Glen Parker" notifications@github.com escreveu:

OK guys,

I think I have the binary and source .zip files ready to go.

I added VS2012 files to git and used them to do the builds. I've got
Net-2.0, Net-3.5+EF, and Net-4.0+EF. There's no Net-4.5 binaries for
2.0.12, so I didn't do one either.

Excellent, Glen!
Although there is no net-4.5 binaries for 2.0.12, I think it would be
worthwhile to create for 2.0.14. I remember I received some reports about
users wanting to use a .net-4.5 only setup but had to install a previous
net version in order to run Npgsql. I think a net45 version would be very
helpful for those cases.

OK. I stole some of Shay's most excellent project file magic and merged it
into the 2.0.12 branch, and re-tagged 2.0.14 (moved the tag up a couple
commits). I have 2.0, 3.5, 4.0, and 4.5 binaries ready to go, and I have
done everything I can see to do to verify they're all really truly targeted
as intended.

But, I think you and/or Josh
should check them over first. Let me know how you'd like me to get them
to
you.

Sure. I'd like to check with you if we could try to make the release
tonight? Josh said it was OK for him tonight after 8pm. Local time. My
current time zone is gmt - 2.

I think we all can check if everything is OK and make the release.

What do you think?

I think that works. I'll be here :)

-Glen

On Sat, Dec 7, 2013 at 3:17 AM, Francisco Figueiredo Jr. <
notifications@github.com> wrote:

Glen, when I tried to add you to pgfoundry, the system said the user name
couldn't be found.
:-(

That's strange, since it knows who I am when I log in :/ I just updated
the email address to this one, and the email address at pgfoundry is
glenebob@users.pgfoundry.org. Maybe those will help you?

-Glen