You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Nov 17, 2023. It is now read-only.
Repository navigation
This repository was archived by the owner on Nov 17, 2023. It is now read-only.
[RFC] New Branches for MXNet 1.x, 1.7.x, and 2.x #17701
Nice. It's an essential step towards MXNet 2.0. Curious to know that do we still encourage contributors to create PR against the master branch? And in what strategy we need pick a commit to branch 1.x? Or they need create two PRs against two branches simultaneously?
Contributors are encouraged to create PR against master branch. Since master branch is the development branch for 2.0, backward incompatible changes will be allowed, while 1.x branch only allows backward compatible changes.
Docs are currently generated from master. What's the proposal for what should be the default version of the docs on the website?
Do we need to escalate the production of docs variations for different versions - like at a minimum, master(2.0) and 1.x?
Even for 1.x, the current instructions are not compatible with stable 1.6 release. We should build the website based on 1.6 release branch until a version selection is available.
@leezu@szha - We need a clear direction on what to do for the current site's docs generation. It isn't really website versioning. It's generating documentation from different branches. The core website jekyll should stay the same and be generated from master. However, the default docs for each API can be generated from a specific version/branch.
It's not only about the API documentation. Installation instructions or tutorials will change over time. Building the website independently for different versions may be the simplest approach. I'm also fine with any other approach that enables users to look up documentation and instructions for their respective version.
Activity
szha commentedon Feb 29, 2020
cc @apache/mxnet-committers
TaoLv commentedon Feb 29, 2020
Nice. It's an essential step towards MXNet 2.0. Curious to know that do we still encourage contributors to create PR against the master branch? And in what strategy we need pick a commit to branch 1.x? Or they need create two PRs against two branches simultaneously?
szha commentedon Feb 29, 2020
Contributors are encouraged to create PR against master branch. Since master branch is the development branch for 2.0, backward incompatible changes will be allowed, while 1.x branch only allows backward compatible changes.
szha commentedon Mar 2, 2020
Pinging @apache/mxnet-committers again in case there's any more concern. Otherwise I will assume lazy consensus by the end of Wednesday of this week.
aaronmarkham commentedon Mar 2, 2020
Docs are currently generated from master. What's the proposal for what should be the default version of the docs on the website?
Do we need to escalate the production of docs variations for different versions - like at a minimum, master(2.0) and 1.x?
szha commentedon Mar 2, 2020
Let's switch the doc generation for the website to 1.x for now. 2.0 doc should be generated when version selection of the website is available.
leezu commentedon Mar 2, 2020
Even for 1.x, the current instructions are not compatible with stable 1.6 release. We should build the website based on 1.6 release branch until a version selection is available.
szha commentedon Mar 4, 2020
Website versioning is tracked in #17497
aaronmarkham commentedon Mar 4, 2020
@leezu @szha - We need a clear direction on what to do for the current site's docs generation. It isn't really website versioning. It's generating documentation from different branches. The core website jekyll should stay the same and be generated from master. However, the default docs for each API can be generated from a specific version/branch.
leezu commentedon Mar 4, 2020
It's not only about the API documentation. Installation instructions or tutorials will change over time. Building the website independently for different versions may be the simplest approach. I'm also fine with any other approach that enables users to look up documentation and instructions for their respective version.
szha commentedon Mar 6, 2020
Let's continue the discussion on website in #17497