GitHubFlow vs GitFlow

[danielmarbach]

Have you guys seen. https://github.com/JakeGinnivan/GitHubFlowVersion

Do we agree that this is also possible with your extension? So why is this fork needed? OK, GitHubFlow doesn't have a develop branch. Why not simply make that step optional here?

[SimonCropp]

Paging @JakeGinnivan do you think it is worth merging these projects?

[JakeGinnivan]

Possibly is, I think they needed to start off separate to make sure we could play with different ideas.

GitFlow is a fair bit more complex, and we also have taken quite different approaches to solving the problem. It is a bit silly having two projects which are so closely aligned to be completely separate.

@danielmarbach I talked to Simon when I started GitHubFlowVersion, the workflows are fundamentally different and at the time it was easier starting again.

We could posibly detect GitFlow if there is a develop branch, if there isn't drop to GitHubFlow?

[danielmarbach]

I think this would be a great place to start. When no develop branch is available then switch to GitHubFlow strategy

[andreasohlund]

Perhaps with an option to set it explicitly in order to enforce a given branch strategy

On Thu, Dec 12, 2013 at 1:03 PM, danielmarbach notifications@github.comwrote:

I think this would be a great place to start. When no develop branch is available then switch to GitHubFlow strategy

From: Jake Ginnivan [mailto:notifications@github.com] Sent: Donnerstag, 12. Dezember 2013 10:38 To: Particular/GitFlowVersion Cc: danielmarbach Subject: Re: [GitFlowVersion] GitHubFlow vs GitFlow (#53)

Possibly is, I think they needed to start off separate to make sure we could play with different ideas.

GitFlow is a fair bit more complex, and we also have taken quite different approaches to solving the problem. It is a bit silly having two projects which are so closely aligned to be completely separate.

@danielmarbach https://github.com/danielmarbach I talked to Simon when I started GitHubFlowVersion, the workflows are fundamentally different and at the time it was easier starting again.

We could posibly detect GitFlow if there is a develop branch, if there isn't drop to GitHubFlow?

— Reply to this email directly or view it on GitHub < https://github.com/Particular/GitFlowVersion/issues/53#issuecomment-30401706> . < https://github.com/notifications/beacon/TUqL6p7Xz6SF-_dIEJ1YBFB7gjrlXZldd6aqAMBThYvxYpX2XoBIK3ddog1JUAEq.gif>

— Reply to this email directly or view it on GitHubhttps://github.com/Particular/GitFlowVersion/issues/53#issuecomment-30413758 .

[JakeGinnivan]

What are we going to name this joined project, and gathering we will just create it under the Particular org.

[danielmarbach]

FlowVersion :D

[JakeGinnivan]

GitVersioner GitSemVer

It will be less about the flow, and more about semantically versioning projects which use Git. Personally I don't like GitHubFlowVersion as a name, so I am all for us joining.

Also, which direction should we go?

[andreasohlund]

GitVersion

Sent from my iPhone

On 12 dec 2013, at 18:17, danielmarbach notifications@github.com wrote:

FlowVersion :D

From: Jake Ginnivan [mailto:notifications@github.com] Sent: Donnerstag, 12. Dezember 2013 18:16 To: Particular/GitFlowVersion Cc: danielmarbach Subject: Re: [GitFlowVersion] GitHubFlow vs GitFlow (#53)

What are we going to name this joined project, and gathering we will just create it under the Particular org.

— Reply to this email directly or view it on GitHub https://github.com/Particular/GitFlowVersion/issues/53#issuecomment-30442022 . https://github.com/notifications/beacon/TUqL6p7Xz6SF-_dIEJ1YBFB7gjrlXZldd6aqAMBThYvxYpX2XoBIK3ddog1JUAEq.gif — Reply to this email directly or view it on GitHub.

[nulltoken]

I'm not very good at naming things, sorry :blush:

However, if you need a (coding) hand, I'd be glad to help!

[JakeGinnivan]

Ok, so I have just migrated @nulltoken's awesome PR detection stuff into GitHubFlow (had started before this came up).

I am very tempted to migrate your stuff into GitHubFlowVersion, rename it to GitVersion then either before or after move it into the Particular org (or another org?).

The reason for that is our integration tests are pretty cool, we create Git repos on the fly and validate at an integration test level. Also, personally I prefer the .exe approach, because I can execute ant scripts or anything else really to support all platforms locally (not just in teamcity) rather than using an MSBuild task.

Thoughts? Happy with that approach?

[JakeGinnivan]

Also can do it the other way, I can start submitting PR's which add support for GitHubFlow and move integration tests across?

You support a lot more scenarios now than you did when I first looked

[andreasohlund]

I believe that githubflow can be supported with just a way to plugin custom impls of our master + feature version finders. How about we spike that and if it works we pull in your finders + integration tests?

In short:

If no develop branch is found then Register GitHubFlowFinders

Thoughts?

Sent from my iPhone

On 14 dec 2013, at 13:42, Jake Ginnivan notifications@github.com wrote:

Also can do it the other way, I can start submitting PR's which add support for GitHubFlow and move integration tests across?

You support a lot more scenarios now than you did when I first looked

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

[JakeGinnivan]

I am having a go at bringing your finders into GitHubFlow, I am happy to look at both. After importing it I have a lot better idea of the issues and how your codebase works.

Maybe have a go at bringing my stuff in, and then we can compare and see which way we want to go. Have a look at:
https://github.com/JakeGinnivan/GitHubFlowVersion/pull/39

Things actually fitted together quite well, either way we go it looks like we will have to make changes to the bootstrapping and ways that you actually use each of them. I went down the exe road so I can run my builds locally as well as teamcity and things still work properly.

There are some things I like about your implementation and also some I like about mine, it would be good to try and end up with something which is the best of both (rather than just an additional strategy on calculating the semver)

[JakeGinnivan]

Here is a breakdown of the things I like and what I think could be improved in each.

GitFlowVersion

What I like

• The installation options, chocolatey, NuGet (for use as a library) and MSBuild task
• Many nice extension methods make the code around dealing with repositories nicer
• Heaps more unit tests around different parts
• The way assemblyinfo patching/updating is done in the MSBuild task

What I would like to be improved/changed

• Proper SemVer support, things like stability and sha's do not belong in the SemVer IMO, and if they are it should all be after the + in the semver. ie {major}.{minor}.{patch}-{tag}+{build metadata}
• AssemblyInfo patching only available in the MSBuild task
• I find the code a bit hard to follow, when I started I switched it over to use DI as an experiment to make things easier for me. I think it turned out well, but would also like your opinions.

GitHubFlowVersion

What I like

• AssemblyInfo patching is just a command line switch on the exe
• Acceptance tests which create a temp git repo, then run the exe to make sure it all works properly
• Can run the build, making environmental variables available to the build process (means it works with any build system, and also works locally)

What I want to improve/change

• Args parser
• Not ILMerged
• Only installation/usage option is by running the .exe

Should we just keep this thread going with the discussion? If we would like to keep this Repo going (which makes more sense as it has more followers etc), should I raise issues if things which I think could be improved and we discuss each issue individually?

[JakeGinnivan]

Reading #13 and all the associated stuff around it, we have a clash in the way we use SemVer.

GitHubFlowVersion is way more simplistic and tries to embrace continuous delivery. I can build a NuGet package in my CI, then simply publish it to NuGet and tag that commit with the version which GitHubFlowVersion generated.

CI builds on develop are NOT semantically versioned which is a source of complexity in GitFlowVersion. You make the semantic versioning decisions when you branch to a release branch, not before. I will go into this more on issue #13. But it is something we need to solve before we can complete this merge

[danielmarbach]

Proper semver doesnt work with nuget :( MsbuildTask is for me crucial. Tired of generating asminfo from buildfiles

Am 15.12.2013 um 13:58 schrieb Jake Ginnivan notifications@github.com:

Here is a breakdown of the things I like and what I think could be improved in each.

GitFlowVersion

What I like

The installation options, chocolatey, NuGet (for use as a library) and MSBuild task Many nice extension methods make the code around dealing with repositories nicer Heaps more unit tests around different parts The way assemblyinfo patching/updating is done in the MSBuild task What I would like to be improved/changed

Proper SemVer support, things like stability and sha's do not belong in the SemVer IMO, and if they are it should all be after the + in the semver. ie {major}.{minor}.{patch}-{tag}+{build metadata} AssemblyInfo patching only available in the MSBuild task I find the code a bit hard to follow, when I started I switched it over to use DI as an experiment to make things easier for me. I think it turned out well, but would also like your opinions. GitHubFlowVersion

What I like

AssemblyInfo patching is just a command line switch on the exe Acceptance tests which create a temp git repo, then run the exe to make sure it all works properly Can run the build, making environmental variables available to the build process (means it works with any build system, and also works locally) What I want to improve/change

Args parser Not ILMerged Only installation/usage option is by running the .exe Should we just keep this thread going with the discussion? If we would like to keep this Repo going (which makes more sense as it has more followers etc), should I raise issues if things which I think could be improved and we discuss each issue individually?

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

[JakeGinnivan]

@danielmarbach in GitHubFlowVersion, if you are in teamcity you just run GitHubFlowVersion.exe /UpdateAssemblyInfo, if you want it to run locally or in teamcity you can do GitHubFlowVersion.exe /ProjectFile MyMSBuildProject.proj or GitHubFlowVersion.exe /ProjectFile MyProject.sln

[JustinThirkell]

MsbuildTask is for me crucial

i'm with @danielmarbach. I think it's great I can ref gitflowversiontask and it all just works. No faffing around with separate build steps - what happens locally is exactly what will happen on TC. I'm really liking the way GFV just does the assemblyinfo patching for me without any extra ceremony - would be a real shame to lose this.

[SimonCropp]

guys shall we try to schedule a skype/google hangouts issue for this?

[JakeGinnivan]

Yeah sounds good :)

Might be easier as there is a heap to discuss. We have all learnt a heap since starting these projects so would be good to quickly run through how we can bring these two projects together and really solve this problem for everyone!

[SimonCropp]

can everyone post what timezones they are in. i will try to schedule something

I am in AEDT

[JakeGinnivan]

GMT for me

[JustinThirkell]

I'm probably more an interested observer than have much to contribute. Sounds good though. NZT for me.

On 16 December 2013 11:54, Jake Ginnivan notifications@github.com wrote:

GMT for me

— Reply to this email directly or view it on GitHubhttps://github.com/Particular/GitFlowVersion/issues/53#issuecomment-30624263 .

Justin Thirkell

Senior Developer

Mobile +64 21 474 752

3 Market Lane, Wellington, 6142, New Zealand, PO Box 24 537

Xero - Beautiful accounting software

[distantcam]

AWST here. Happy to help out as I'd really like SemVer 2 support.

[andreasohlund]

GMT

On Mon, Dec 16, 2013 at 7:19 AM, Cameron MacFarland < notifications@github.com> wrote:

AWST here. Happy to help out as I'd really like SemVer 2 support.

— Reply to this email directly or view it on GitHubhttps://github.com/Particular/GitFlowVersion/issues/53#issuecomment-30637980 .

[SimonCropp]

Correct my math if needed

So 7am GMT is the following time for everyone

Andreas GMT 7am Jake GMT 7am Simon AEDT 6pm Cam AWST 3pm Justin NZT 8pm Dan CET 8am Em CET 8am

Would this be do-able?

How about this Sunday (which would seem to be Sunday for all of us)

[robdmoore]

Bit late to the party, but I'm interested in this too; I helped out with the original acceptance tests on GitHubFlowVersion and some of the original brainstorming (aka stubborn arguing about what constitutes continuous delivery :P) with Jake. Don't have a huge amount of time to spare though, but definitely keen to keep across it and help out where I can. I assume you've already had the Hangout last Sunday?

[JakeGinnivan]

We didn't do it, I am travelling at the moment. Maybe next Sunday after the new year is over? I am off to Hogmanay tomorrow!

[JakeGinnivan]

Does tomorrow work for everyone at the times @SimonCropp mentioned above?

[robdmoore]

Fine by me - I'm same as Cam 3pm AWST

[andreasohlund]

Both Simon and me are flying to Tel Aviv. We need to push it back one more week:(

Sent from my iPhone

On 4 jan 2014, at 14:12, Jake Ginnivan notifications@github.com wrote:

Does tomorrow work for everyone at the times @SimonCropp mentioned above?

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

[JakeGinnivan]

Thats fine with me, Saturday or Sunday next week better for everyone?

[robdmoore]

Either works for me

[distantcam]

Might be easier as there is a heap to discuss. We have all learnt a heap since starting these projects so would be good to quickly run through how we can bring these two projects together and really solve this problem for everyone!

At this point won't it be easier to just discuss things as issues?

[JakeGinnivan]

I'm happy both ways. Things like CI builds and how to deal with that would be more efficient on skype.

I have started putting up a few pull requests which move the GitFlowVersion code-base to a point where it can support both branching strategies, I am happy to incrementally put pull requests up and eventually make GitHubFlowVersion obsolete

[distantcam]

Things like CI builds and how to deal with that would be more efficient on skype.

We've been trying to organize this Skype meeting for 3 weeks now. I think at this point it would have been more efficient to organize everything on GitHub instead.

[andreasohlund]

If no one comes up with another name I will go ahead and rename this project to GitVersion during the weekend

[andreasohlund]

I've renamed to GitVersion and added issues for various renames that still needs to happen. Closing this one