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

Fixes and updates to es_ES #136

Open
wants to merge 3 commits into
base: master
Choose a base branch
from

Conversation

JakeSmarter
Copy link
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
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
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
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.

None yet

2 participants