Can Docusaurus produce versioned docs based on git branches?
The docs promote a method that has you maintain versions in duplicated version directories.
I'd like to maintain version branches in a docs repo: branch-v1, branch-v2, branch-v3, and so on. And I want the SSG to published versioned docs based on those branches.
Any thoughts on whether this is possible?
Thanks!
Related
Is there a best way to publish a previous major version of an npm package without adding a tag for it? Our current major version is 3.x (v3) so we npm publish that version to automatically give it the latest tag. When we publish updates to the 2.x version (v2) we have to give it a tag so that it doesn't automatically grab the latest tag from v3.
We could do something like previous, though the meaning of that is subjective. Really we don't need a tag for v2 at all. Semver works great if people want to install v2. Is there a better solution to not add unnecessary tags than publishing it with a tag and adding a postpublish script that deletes the tag? (That sounds ridiculous as I write it)
Looking at this comment from 2015, "Every publish must be associated with a dist-tag, by design." And I don't see a way to bypass the tag in the current code of libnpmpublish and npm, unfortunately.
Thus, I think you have the best options laid out already: publish under another tag, whether that tag is temporary or not.
However, if I could make a suggestion...
Instead of the subjective previous tag, you could consider publishing the previous versions under a tag called v2. This is a pattern that I've noticed the Angular team uses for LTS releases, for example:
While I think it's of minimal use to a consumer since they could just npm install #angular/core#11 instead of npm install #angular/core#v11-lts, nonetheless it might be a cleaner approach to publish.
I'm looking for a way to install the ingest-attachment plugin in offline mode.
So to do it i first need download the zip distribution of this plugin.
Official documentation (https://www.elastic.co/guide/en/elasticsearch/plugins/master/ingest-attachment.html) provides a non working link on their artifact repository
Would anyone have an idea where to download a stable/released zip version of this plugin ?
Many thanks.
Ok seems like the link they propose is broken cause the version does not exist anymore in their artifact repository.
I had to get a previous version (5.1.1) instead. It's just a shame they do not track any dead link in their documentation for massive indexation / analytics products company... or at least propose a clear URL to browse all available versions.
I'm playing a bit with the new Microsoft.AspNet.Identity but the 3.0.0-beta2 looks very different from the current state of affairs in git. I'd like to build against he git version.
I seem to remember hearing that it possible to reference a git repository directly from the dependencies in project.json. How does one do that? What's the syntax?
There are two options:
Instead of using the NuGet feed, switch to the Nightly feed on MyGet. We produce builds on every checkin from the code in Git. The latest versions on the MyGet feed are beta4-*
Clone the repo and use global.json to point to the sources, as described in this article
Adding a reference directly to a Git repo without cloning it beforehand is not supported.
I am new to this forum but i found very quick responce from active developers.
i have query with technical diffrence between "GIT" and Tortoise "SVN". if any one has work on it please give me detail description.
thanks
tousif shaikh.
You mean surely a difference between Git and svn? Tortoise is just a GUI for (mostly) svn.
Take a look at this wiki article: https://git.wiki.kernel.org/index.php/GitSvnComparison
or at this thread: https://stackoverflow.com/a/161572/1758762 :
SVN is one repo and lots of clients. GIT is a repo with lots of client repos, each with a user. It's decentralised to a point where people can track their own edits locally without having to push things to an external server.
SVN is designed to be more central where GIT is based on each user having their own GIT repo and those repos push changes back up into a central one. For that reason, GIT gives individuals better local version control.
and so long ...
SVN workflow:
The trunk directory represents the latest stable release of a
project.
Active feature work is developed within subdirectories under branches
When a feature is finished, the feature directory is merged into
trunk and removed.
Git workflow :
A Git repository stores the full history of all of its branches and
tags within the .git directory.
The latest stable release is contained within the master branch.
Active feature work is developed in separate branches.
When a feature is finished, the feature branch is merged into master
and deleted.
I feel that using Git submodules is somehow troublesome for my development workflow. I've heard about Git subtree and Gitslave.
Are there more tools out there for multiple repository projects and how do they compare ?
Can these tools run on Windows ?
Which is best for you depends on your needs, desires, and workflow. They are in some senses semi-isomorphic, it is just some are a lot easier to use than others for specific tasks.
gitslave is useful when you control and develop on the subprojects at more of less the same time as the superproject, and furthermore when you typically want to tag, branch, push, pull, etc all repositories at the same time. gitslave has never been tested on windows that I know of. It requires perl.
git-submodule is better when you do not control the subprojects or more specifically wish to fix the subproject at a specific revision even as the subproject changes. git-submodule is a standard part of git and thus would work on windows.
git-subtree provides a front-end to git's built-in subtree merge strategy. It is better when you prefer to have a single-repository "unified" git history. Unlike the subtree merge strategy, it is easier to export changes to the different (directory) trees back out to the original project, but it is not as automatic as it is with gitslave or even git-submodule.
repo is in theory similar to gitslave, but not as well documented for non-android operations that I have found. It is fairly dedicated to the Google Android development model and only natively supports a handful of git commands (though you can run arbitrary commands) and the limited native support doesn't support, for example, a centralized repository to push to and checking out a branch seems fairly difficult.
kitenet's mr is what you would want to use if you have multiple version control systems in use, but is mostly limited for git-only superprojects due to its lowest common denominator approach. There are ways to run arbitrary commands, but they are not as well integrated.
For some use cases, I have liked each of the following two simple approaches:
Nested repositories. If your software project has a plugin mechanism, with each plugin in its own sub-directory, it can make sense to git-ignore these plugin directories and, in your local filesystem, to make each of them into its own git repository. This way, all your files form a single directory tree, but are managed in different git repositories. It will not confuse git.
Per-package repositories. For software projects where you use some kind of source code package management system (gem / bundler, npm, pear or the like) it can make sense to put your re-used code into separate git repositories, then to make source packages from them, and then to install them with the package management tool into the parent project. Your parent project's git repository would only contain a reference to the required packages and their versions, while the actual code of these packages will be git-ignored as done with all other packages and external libraries as well. Compared to the nested repositories proposed above, this is a more elaborate approach as it allows to specify which package version is to be installed.
I currently use submodules for development and not just relating 3rd party libraries. There are some ways that you can make life easier with submodules, especially when they are the source of merge or rebase conflicts. Look to ls-tree to get the 2 commits involved on a conflict in the submodule. This is probably the most difficult part of submodules for people to deal with. For now scripting will make this much easier to work with. Future versions of Git should have better native support for dealing with them.
Hope this helps.
We encountered a similar issue when using Git submodules in projects where we had dependencies in a variety of languages. To deal with them, we built and open-sourced a tool called MDLR ("Modular") that gives you declarative version-controlled Git dependencies with similar functionality to Git submodules, but without the annoying workflow. You can install it and manage your dependencies with the instructions/downloads on the GitHub repo