Work on 3.0 and 2.2

[Shay Rojansky]

Hey Npgsql devs.

Francisco just released 2.2.0 which is great. I've started working on 3.0 in our master branch which will be pretty major, so we will need to be able to work on 2.2 bugfix releases in the meantime. Here are some notes/ideas on how to do this.

• Commits should in general be made to master (3.0), and if we want to backport them, cherry-picked into the 2.2 branch I just created.
  
• PRs and issues which get cherry-picked this way should have the backport label
• When we want to release a 2.2.x bugfix release, we tag the commit in the 2.2 branch and release. Then work can continue on 2.2 if needed.
• We can use github milestones for 2.2.x bugfixes releases as usual.
• Some 2.2.x bugfixes might not be relevant for 3.0 (or might need to be implemented differently), in this case we can commit directly to the 2.2 branch (although this should only be happen if really necessary).

I just backported two PRs into 2.2 (see the milestone here).

Let me know if you have any suggestions etc...

Shay

[Francisco Figueiredo Jr.]

One suggestion I have regarding the commits backported is that we use the following syntax for cherry-pick:

git cherry-pick -x -e <commit-id>

then we can add message:

Backport from #pr

Here is an example commit message:


Remove Tools/vssdk*_tools/inc folder.

This folder contains only .h files which aren't used by Npgsql and takes a large space.

(cherry picked from commit 7092c6d)

Backport from #293



This way, it would become easier to find if an specific commit was applied to the branch.
Also, by adding the "Backport from #pr" will make this commit appear in the pr discussion and we will be able to easily see that it was applied.
I remember I saw this idea somewhere in the stackoverflow but I'm not finding the reference right now.

For example, in the #293 I can see the commit done in the release-2.2.0 branch.

https://github.com/npgsql/Npgsql/pull/293

[Shay Rojansky]

Great suggestion Francisco, I didn't know about -x! I wonder why it isn't the default behavior for cherry-pick.

You're starting to teach me about git :)

[Francisco Figueiredo Jr.]

On Wednesday, September 3, 2014 3:58:24 PM UTC-3, Shay Rojansky wrote:

Great suggestion Francisco, I didn't know about -x! I wonder why it isn't the default behavior for cherry-pick.

Yes. It would be very nice if it was the default. From the documentation it seems that it was the default once but has been changed:


-r

    It used to be that the command defaulted to do -x described above, and -r was to disable it. Now the default is not to do -x so this option is a no-op.


At least I think we can set up an alias for it, can't we?

 

You're starting to teach me about git :)

:D

I'm glad to know I'm being able to give some new information to my git master guru :)

I was looking for a way to check if a commit was applied to a branch when I found information about this command argument.

I learned about the git branch --contains <commit> command but in the case of cherry-pick it creates a new commit id and so it wouldn't work.

This cherry-pick syntax would help us with the git log --grep=word command.

 

[Shay Rojansky]

One last thing regarding .NET 2.0 and 3.5 and the build server...

The situation is a bit complicated because we now have two branches: 2.2 which supports the old frameworks and master which doesn't. I therefore duplicated the "All" build config as All-2.2. Commits to branch 2.2 - and only to 2.2 - will trigger builds of All-2.2, including the old frameworks. All commits will trigger builds of All, which will build only the newer frameworks. Once we release Npgsql 3.0 I'll kill the All-2.2 build config.