There's no contribution guide about learn HOT 10 CLOSED

Good idea. The branch a PR should be created against is not clear indeed.

If you want to write a draft, global idea is anything that should be updated right now, for the current version of UF should be in master. Anything new for the next minor version of UF (4.2.x) should be in hotfix, and new stuff for the next major version (4.x.x) should be in develop. Old version can also be fixed by pushing to old branch (4.1, etc.).

Now that I think of that, probably #86 should be against master. Getting confused with stuff that will need to be merged back later into other branch...

from learn.

@lcharette Good read. Thanks for the article. While my current CI/CD pipeline is not complete yet I can't say there's much for me to complain about. Granted, I do use plain old bash commands so maybe deployer is getting in the way? We'll see how I feel about this in a couple of weeks.

As for the contributing guide on the UF code side, I did only skim over it so I obviously missed the bit about the learn repository. Thank you. I'll update my PR to match the main UF repository.

from learn.

Merged. Thanks !

from learn.

1. doc changes for a previous release go into the release respective branch. Fine;
2. doc changes for the next breaking change release (e.g. 5.x.x or 4.x.x) go into develop. Fine;
3. doc changes for the next non-breaking release (e.g. 4.2.x) go into hotfix. Odd;

If master is automatically published via some CI/CD pipeline then (3) is also fine and PRs for things which are applicable to all versions should indeed be made against master and maybe annotated with "available since version x.y.z" if applicable.

Also I've made #88 so @lcharette please take a look if you feel like it. Thanks! 😄

from learn.

If master is automatically published via some CI/CD pipeline

No it's currently not.

from learn.

@lcharette Should it be?

from learn.

@lcharette Should it be?

Are always open to suggestions for improvements.

from learn.

@unguul automatically published via some CI/CD pipeline? I've got BAD experience with deploying Grav based sites...

from learn.

@amosfolz I've worked with gitlab in the past for CI/CD of web apps. I can't imagine travis or circle ci (I noticed they're more popular among github projects) to be much different (could be wrong). As per my comment at #87 (comment) , would such a setup make sense?

1. master holds the docs for whatever version is currently the latest;
2. develop is for whatever is currently in development;
3. 4.x.x is for that specific version

This means that PRs are made against develop so they get published when develop gets merged into master. PRs can also be made against 4.x.x if the changes are only applicable to that specific version. We'd still have to duplicate a PR if it applies to other versions.

Having multiple version of something out there increases the complexity of maintaining it quite a bit, eh?

@lcharette Interesting. I just started a Grav based project where CD is a requirement. Any pro tips ?

from learn.

@unguul See https://bbqsoftwares.com/blog/deployment-permission-nightmare. I gave up after that, as it's so unreliable.

As for PR, one could also be make against master or hotfix. If current version is 4.2.3, we might want to push a fix now (master) and not wait for 4.3 (develop). We could also prepare a change for the upcoming 4.2.4 (hotfix) while not pushing it live already (less likely to happen).

Have you seen this? https://github.com/userfrosting/UserFrosting/blob/master/.github/CONTRIBUTING.md#branches

from learn.