0install: Unterschied zwischen den Versionen
Zur Navigation springen
Zur Suche springen
(Remove lone round opening bracket. Remove subjective adjective epic.) |
(Clarify depending.) |
||
| Zeile 7: | Zeile 7: | ||
* on all operating systems. | * on all operating systems. | ||
* version control. | * version control. | ||
| − | * | + | * depending on modules in any revision range (unlike Git submodules) |
| − | * automatic backup of projects. | + | * distributed using any version control or package management system |
| + | * following API dependent release versioning conventions (incompatible_api_change_increment.minor_version.fix-release_candidate_or_suffix) for being able to specify a wider compatible version range | ||
| + | * automatic backup of projects (because of distributed development). | ||
* easy testing of modules locally without breaking the system due to multiple versions of a package. | * easy testing of modules locally without breaking the system due to multiple versions of a package. | ||
* developer interaction (world wide team work) without being forced to release just to allow other developers to fetch the new changes (because Git is the base system) | * developer interaction (world wide team work) without being forced to release just to allow other developers to fetch the new changes (because Git is the base system) | ||
| Zeile 14: | Zeile 16: | ||
* easily fetching, inspecting the sources of a project in a certain version. (e.g. to debug or further develop / fork a local version, this can be rebased later on) | * easily fetching, inspecting the sources of a project in a certain version. (e.g. to debug or further develop / fork a local version, this can be rebased later on) | ||
* preventing dependency mess. | * preventing dependency mess. | ||
| − | * linear project history (not mandatory but possible) and all other | + | * linear project history (not mandatory but possible) and all other version control system powers. |
* having the 0install XML file under version control where it belongs: in the same repository where the project sources reside. | * having the 0install XML file under version control where it belongs: in the same repository where the project sources reside. | ||
* aliasing filenames a project depends upon to a functional general name to be able to exchange a file (e.g. a used image or schematic) later without updating all used references e.g. in FreeCAD or blender files (which may be binary where search replace does not work easily). | * aliasing filenames a project depends upon to a functional general name to be able to exchange a file (e.g. a used image or schematic) later without updating all used references e.g. in FreeCAD or blender files (which may be binary where search replace does not work easily). | ||
Version vom 28. Dezember 2016, 01:42 Uhr
Why
0install is used as cross-platform dependency resolver for not having to package the projects' releases for multiple package managers.
This allows:
- modular, flexible development (single source principle).
- using the same toolchain for developing all kinds of projects (not only code)
- on all operating systems.
- version control.
- depending on modules in any revision range (unlike Git submodules)
- distributed using any version control or package management system
- following API dependent release versioning conventions (incompatible_api_change_increment.minor_version.fix-release_candidate_or_suffix) for being able to specify a wider compatible version range
- automatic backup of projects (because of distributed development).
- easy testing of modules locally without breaking the system due to multiple versions of a package.
- developer interaction (world wide team work) without being forced to release just to allow other developers to fetch the new changes (because Git is the base system)
- users turning into developers with ease (because 0install is used for releases and can fetch the sources, i.e. the Git repository contents).
- easily fetching, inspecting the sources of a project in a certain version. (e.g. to debug or further develop / fork a local version, this can be rebased later on)
- preventing dependency mess.
- linear project history (not mandatory but possible) and all other version control system powers.
- having the 0install XML file under version control where it belongs: in the same repository where the project sources reside.
- aliasing filenames a project depends upon to a functional general name to be able to exchange a file (e.g. a used image or schematic) later without updating all used references e.g. in FreeCAD or blender files (which may be binary where search replace does not work easily).
- referencing files of dependencies using relative links (as if the dependencies were located as a folder in the current working directory
- to increase development consistency.
How to package
A module package version is released directly in the Git repository. See 0install, git interaction outlined under #Why.
It is packaged using the repository contents. => No magic extra ingredients to be figured out, then merged.
The resulting package can be hosted in the version control repository but it might be desirable to have it separate for big release data amounts. The package URI is provided in the 0install XML file.
How to install, depend on a module
Install a module / package:
0install add <repository.uri>/<module>.xml
Depend on a module by using the 0install XML file URI of the corresponding module repository.