Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add .openapi-generator/VERSION to .gitignore #245

Closed
wing328 opened this issue Jun 7, 2018 · 8 comments
Closed

Add .openapi-generator/VERSION to .gitignore #245

wing328 opened this issue Jun 7, 2018 · 8 comments

Comments

@wing328
Copy link
Member

wing328 commented Jun 7, 2018

Description

We will need to create the following branches (for breaking changes with/without fallbacks)

  • 4.0.0
  • 3.1.0

We will need to sync enhancements, bug fixes from master (currently 3.0.1) to these branches from time to time so I suggest we whitelist .openapi-generator/VERSION in gitignore to avoid merge conflicts during the sync.

openapi-generator version

Latest master

Suggest a fix/enhancement

Add .openapi-generator/VERSION to .gitignore

@jmini
Copy link
Member

jmini commented Jun 7, 2018

-1 for me.

First reason:
It it useful to see when the sample was generated. It is valuable information.

Second reason:
During a merge 3.0.x -> 4.0.0 everything that is under samples/ needs to be ignored, it has no value as code. It is a derived artifact that is really important as part of our CI, quality insurance process.

You can have conflicts everywhere inside samples/ and the strategy will always to ignore all conflicting changes inside samples/ (I think with git reset -- samples/ or git checkout -- samples/) and then regenerate all samples (and because we can not regenerate all samples/ we can restrict to the one listed in bin/ensure-up-to-date) in order for the CI to be OK.

Third reason:
The conflict will only occur when the version change 3.0.1-SNAPSHOT -> 3.0.2-SNAPSHOT on master branch that is merged on 4.0.x branch. Once it is merged with a merge commit the conflict will no longer appear.


I am glad you start to discuss branching strategy, because I wanted to ask the question in a public area like this.

Can you elaborate a little bit on Branch names?

@jimschubert
Copy link
Member

I think the intention of this issue is to reduce noise on merge, not to address all merge conflicts. In many cases, samples are very close between branches and resolving a simple merge resolution is easier (and probably better) than a force reset of the folder.

@jmini
Copy link
Member

jmini commented Jun 7, 2018

As I wrote, the conflict resolution will be really easy and something like:

git checkout --ours samples/**/VERSION

The old way of writing this:

git reset -- samples/**/VERSION

(needs to be tested when we do the first merge, I just guessed the syntax)

One-liner, all conflicts on VERSION files solved in one command.
Thoe conflicts on VERSION will only occur after each release (and each merge to the other branches).


@jimschubert, you are missing my first and main argument here:

Since our samples/ folder is most of the time outdated, not having the version information is a big loss when we we do a modification in the generator and try to figure out its influence on a samples/.

@wing328
Copy link
Member Author

wing328 commented Jun 7, 2018

Can you elaborate a little bit on Branch names?

4.0.0 is the next major release containing breaking changes with no fallback

3.1.0 is the next minor release containing breaking changes with fallback.

3.0.1 is the upcoming patch release due this coming weekend.

@wing328
Copy link
Member Author

wing328 commented Jun 7, 2018

I agree the VERSION can be useful in some cases so let's keep it for the time being and I'll document the procedure in keeping next minor, major branch in sync so that we can review to see if we can come up with better procedure/process to automate the sync or resolve the merge conflicts more easily.

@jmini
Copy link
Member

jmini commented Jun 7, 2018

4.0.0 is the next major release containing breaking changes with no fallback
3.1.0 is the next minor release containing breaking changes with fallback.
3.0.1 is the upcoming patch release due this coming weekend.

Well OK. Thank you.


For the branches:

3.0.1 is on the master branch. This stays that way?
Then we create two more branch 4.0.x and 3.1.x? (or 4.0.0 and 3.1.0; or 4.0 and 3.1)

Merge direction is: master -> 3.1.x -> 4.0.x.
When we are over with the 3.0.x stream we will merge 3.1.x back to master to publish a first 3.1.0 version?

@wing328
Copy link
Member Author

wing328 commented Jun 7, 2018

3.0.1 is on the master branch. This stays that way?

Yes (before the release) and of course you know we'll change it to 3.0.2 after the release.

When we are over with the 3.0.x stream we will merge 3.1.x back to master to publish a first 3.1.0 version?

Yes, when we drop the support for 3.0.x, we'll merge 3.1.x into master

@jmini
Copy link
Member

jmini commented Jun 25, 2018

I have documented some git command examples in the section Solving conflicts during merge

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants