-
Notifications
You must be signed in to change notification settings - Fork 153
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
Showing
11 changed files
with
28 additions
and
66 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file was deleted.
Oops, something went wrong.
File renamed without changes.
File renamed without changes.
File renamed without changes.
File renamed without changes
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
File renamed without changes.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
265feb0
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jackfoxy Why did you remove the target ReleaseDocs?
I can't find any good reason in the commit message and this was the target I used the most.
265feb0
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@gusty don't remember exactly, but probably because it is no longer needed. This PR, and a later one that renames docsraw folder to docsrc, changes the scaffold infrastructure to allow the more recent and simpler method of publishing docs on GitHub by simply enabling github.io to publish the "docs" folder in the master branch. No more hassling with a git orphan branch named gh-pages.
265feb0
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
265feb0
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @jackfoxy at the same time you replied I found the issue #304 and it seems I'm not the only one who miss this.
But can you tell me what's the process to Release only the docs with a single command now?
265feb0
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@gusty Docs get released with the master branch. I'm not opposed to rolling back ProjectScaffold. Or reimplementing ReleaseDocs in a new PR can't be that hard. I just thought, and still do think, the gh-pages way of maintaining docs is complicated for people not too familiar with git.
I only have my own experience to go on. Everyone develops their own workflow. I still think (but have no evidence) most new adopters would rather not deal with gh-pages. Do they really want their published docs to not correspond to the master branch? Again, PR to put ReleaseDocs back in and both methods work.
Anyway, I also think the future of ProjectScaffold is for people to maintain their own forks. I maintain my own fork. Publishing a directory of interesting forks might be a good idea.
265feb0
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
265feb0
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So there's no way to release the docs with a single command, as it was before.
I agree, it is complicated to set up, but once done it's quite easy to update. This can be solved with a very detailed guide on how to set up gh-pages step by step.
Apart from that I agree with @forki in that docs are like the .exe or the .dll that is produced by the source files, so it shouldn't go into the source code.
Not sure. Let's think about independent features: Feature A, Feature B and Feature C where one of these features is the docs. Now if we start forking we'll have Feature A' with B and C, or B' with A and C, but then someone prefers A' with B' but with C and so on. We'll need to have many combinations and that's hard to maintain.
So I think if we want to have different features, we should implement them all and ask the user when setting up his project which one he prefers.