Skip to content

Fixes and updates to es_ES#136

Open
JakeSmarter wants to merge 3 commits intoWP-for-Church:masterfrom
JakeSmarter:i18n
Open

Fixes and updates to es_ES#136
JakeSmarter wants to merge 3 commits intoWP-for-Church:masterfrom
JakeSmarter:i18n

Conversation

@JakeSmarter
Copy link
Copy Markdown
Contributor

I have fixed all the issues outlined in b46d381. Vince LaRue should review fuzzy marked messages.

master should be reset on the head of this i18n branch. Of course, you can always cherry pick onto the existing master but this will not fix the revision history. There are more commits which need cleanup or squashing but this should do for the start.

@nikola3244
Copy link
Copy Markdown
Contributor

Hey, thanks for the PR, but it won't be merged into master. :)

In the previous (non-defined) workflow, and in the current (strictly-defined Git Flow), every commit on master is a release [which will trigger scripts to roll-out the plugin to production (wp.org)].

So therefore, I can't accept this commit in this state. Please switch the base to dev and push only the commits related directly to es_ES, other changes will get their own PRs.

Workflow example [without feature, hotfix and release branches (which we do use)]:

You can read more about current workflow here.

Thank you again, but I just want to make sure that everything is where it should be - and you prompted me to start taking more care about it. :)

@JakeSmarter
Copy link
Copy Markdown
Contributor Author

In the previous (non-defined) workflow, and in the current (strictly-defined Git Flow), every commit on master is a release [which will trigger scripts to roll-out the plugin to production (wp.org)].

This is not what the Gitflow work flow is about.

So therefore, I can't accept this commit in this state. Please switch the base to dev and push only the commits related directly to es_ES, other changes will get their own PRs.

Then I cannot help you. Good luck.

You can read more about current workflow here.

Thank you again, but I just want to make sure that everything is where it should be - and you prompted me to start taking more care about it. :)

I am well familiar with the Gitflow work flow, so I do not need a lecture on this. Unfortunately, you have fallen into the same trap like all the other lemmings do who do not think over what they are doing. Just because you have found a work flow and have finally decided on the first one which came along, does not mean you have adopted it or that the repo is ready for it. But, what is even more important is that just choosing a work flow or rather a release strategy does not mean that it suits your project best.

@nikola3244
Copy link
Copy Markdown
Contributor

This is not what the Gitflow work flow is about.

Well, I certainly did not make it up. Take a look:

We consider origin/master to be the main branch where the source code of HEAD always reflects a production-ready state.

and here:

Therefore, each time when changes are merged back into master, this is a new production release by definition. We tend to be very strict at this, so that theoretically, we could use a Git hook script to automatically build and roll-out our software to our production servers everytime there was a commit on master.

(source)

Please let me know if I have read it incorrectly.


Then I cannot help you. Good luck.

Okay, thanks, not a problem. I will take a look through the commits and see how to sort this out.
But it will take time.


[...] does not mean you have adopted it [...]

Hm, I'm pretty sure that it is adopted, as you can see from the current state of the repository.
master represents the master of the Git Flow workflow,
dev represents develop,
feature/* represents feature branches,
hotfix/* hotfix, etc, etc
It's exactly the way it should be. :)

[...] or that the repo is ready for it.

You are right here, and I apologize. The repo is currently used only between you and me, and I think that I should have firstly somehow notified you so we can go through the change together and not have this messy situation in the first place.

But since the issue is caused by me, I'll do my best to resolve it. Please do not do any more work until it's resolved. After that, just make a fresh fork. :)

But, what is even more important is that just choosing a work flow or rather a release strategy does not mean that it suits your project best.

I'd argue that this suits the project perfectly. We had a similar workflow until this one, and this is just like an upgrade to it. Nothing is getting broken and it's backwards compatible with previous work, we just have a small in the work from the past week or two.

This is all new for me, or else I would do it Git Flow way in the first place. Mistakes were expected to happen, and it's good that they are just small mistakes. All I ask now is a bit of patience. :)

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants