0install - Versionsgeschichte

Andreas Plank: Hilfe:Kategorisieren von Seiten: Ergänze Kategorie:English pages

2022-08-15T18:49:04Z

Hilfe:Kategorisieren von Seiten: Ergänze Kategorie:English pages

Jan R.B.-Wein: /* Why */ Explicitely note 3 more arguments related to aliasing and relative references, including the notion of immunity against breakage through file renames.

2017-06-18T19:19:58Z

Why: Explicitely note 3 more arguments related to aliasing and relative references, including the notion of immunity against breakage through file renames.

Jan R.B.-Wein: /* Why */ State significant advantages of the relative link strategy: fewer links, automatically maintained rather than having users maintain links which will break.

2017-06-18T14:06:39Z

Why: State significant advantages of the relative link strategy: fewer links, automatically maintained rather than having users maintain links which will break.

Jan R.B.-Wein: /* Prefer tagging over suffixes for classification */ Iron out inconsistencies.

2017-06-18T14:00:47Z

Prefer tagging over suffixes for classification: Iron out inconsistencies.

Jan R.B.-Wein: Add tags: organization, toolchain, workflow, worlddevelopment

2017-06-18T11:54:13Z

Add tags: organization, toolchain, workflow, worlddevelopment

Jan R.B.-Wein: /* Why */ Clearly state that sources of a version can be inspected but it is different to a full source repository download which is always one version: the development version, i.e. FETCH_HEAD

2017-06-18T11:50:51Z

Why: Clearly state that sources of a version can be inspected but it is different to a full source repository download which is always one version: the development version, i.e. FETCH_HEAD

Jan R.B.-Wein: /* Platform and content independent dependency resolution */ Manually -> Manual . Add (not yet)

2017-06-18T11:40:01Z

Platform and content independent dependency resolution: Manually -> Manual . Add (not yet)

Jan R.B.-Wein: Add section about What 0install (feed) is used for. Clarify dev vs. release versions. Improve Why.

2017-06-18T11:37:51Z

Add section about What 0install (feed) is used for. Clarify dev vs. release versions. Improve Why.

Jan R.B.-Wein: /* How to package */ Correct typo farietree -> faerietree

2017-01-01T21:14:43Z

How to package: Correct typo farietree -> faerietree

Jan R.B.-Wein: /* How to package */ Reference the 0install tools documentation and recommend usage of 0repo. Link freecad_convert example.

2017-01-01T21:13:13Z

How to package: Reference the 0install tools documentation and recommend usage of 0repo. Link freecad_convert example.

← Abfassung vorher		Version vom 15. August 2022, 18:49 Uhr
Zeile 287:		Zeile 287:
	[[Category:workflow]]		[[Category:workflow]]
	[[Category:worlddevelopment]]		[[Category:worlddevelopment]]
		+	[[Kategorie:English pages]]

@@ Zeile 70: / Zeile 70: @@
-* 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). This prevents name conflicts as it is up to the module developers to choose a suitable one (unique URI per module). This means e.g. files from different dependencies with the same file name can still be used.
-* referencing files of dependencies using relative links (as if the dependencies were located as a folder in the current working directory). This shifts the risk of broken links away from many user maintained links to fewer system maintained ones. This implies that it is fine to have files organized across folders.
+* referencing files of dependencies using relative paths within the module's directory thanks to links. This shifts the risk of broken links away from many user maintained links to fewer system maintained ones. Note this implies that it is fine to have files organized across folders.
-* to increase development consistency.
+* aliasing and relative references (see preceding arguments) together make modules immune to file renames in other modules it depends upon.

@@ Zeile 71: / Zeile 71: @@
 * 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).
+* referencing files of dependencies using relative links (as if the dependencies were located as a folder in the current working directory). This shifts the risk of broken links away from many user maintained links to fewer system maintained ones. This implies that it is fine to have files organized across folders.
 * to increase development consistency.

@@ Zeile 201: / Zeile 201: @@
 === Prefer tagging over suffixes for classification ===
-Call a world module 'bending_machine' or 'sheet_bender' is a subjective decision. A machine can be automated turning the _machine suffix invalid. Yet the base module is a machine and not automated and if an automated self contained version were to be developed then a new repository 'bending_automaton' may be useful because it allows completely different design by turning the human machine interface into a radio control that interfaces the computers that actually control the machine automatically.
+Whether to call a world module 'bending_machine' or 'sheet_bender' is a subjective decision. A machine can be automated rendering the _machine suffix unspecific.
-In the ''bender'' example one may extend/inherit the modules
+All this however needs not necessarily be encoded in the naming scheme as this leads to redundant information that needs be maintained. Thus sheet_bender is a valid, quite specific name of the module and still allows to tag it with `machine`, `manufacturing`, `processing`, ...
 * bending (for the general process/documentation of such manufacturing process)
 * sheet_bender (may be a simple tool)
 * tube_bender (bender__tube_tool or bender_tube_bracket may inherit from this one for documentation or to reuse the manually operated tool, e.g. the brackets/clamps to create nicely shaped bends)
-As it is questionable if a module ''bender'' rather refers to an active operator that bends something, i.e. a mobile automaton that changes location to bend something while bending_machine implies some static design. Consider a car, it is not static and yet a machine.
+Is it is not obvious whether a module ''bender'' refers to an active operator that bends something, i.e. a mobile automaton that changes location to bend something or whether bending_machine implies some static design. Consider a car, it is not static and yet a machine.
-''=> Thus bender is valid too and hence system -> machine -> automaton -> robot -> android classification left to tagging (categories).''
+''=> Thus bender is valid too and hence classification (e.g. system -> machine -> automaton -> robot -> android) left to tagging (categories).''
 Tags (like machine, automaton, manufacturing, energy, ...) should be included in every repository. Either as
 * tag / category list in the 0install feed or
-* as files in a directory called ''tags'' (''.tags'' may not be found when not directly searching for hidden files too). This allows finding projects in the local file system without having to open XML files for reading, parsing.
+* as files in a directory called ''tags'' (''.tags'' may not be found when not directly searching for hidden files too). This allows finding projects in the local file system without having to open XML files for reading, parsing. (performance gain)
-The tags/<tag> empty files may be generated from the 0install XML feed file automatically which effectively turns this into an cache which may become invalid (something to be aware of).
+The tags/<tag> empty files may be generated from the 0install XML feed file automatically which effectively turns this into a cache which may become invalid (something to be aware of).
 === Prepending versus Appending ===

← Abfassung vorher		Version vom 18. Juni 2017, 11:54 Uhr
Zeile 278:		Zeile 278:

	Using __ also increases compatiblity as tools that rely on just a single underscore as separator can easily replace __ with _ and proceed as usual. Whereas when using hyphens - as separator it is not possible to replace all instances of - with _ without detecting which words are composites (e.g. add-on).		Using __ also increases compatiblity as tools that rely on just a single underscore as separator can easily replace __ with _ and proceed as usual. Whereas when using hyphens - as separator it is not possible to replace all instances of - with _ without detecting which words are composites (e.g. add-on).
		+
		+
		+	[[Category:organization]]
		+	[[Category:toolchain]]
		+	[[Category:workflow]]
		+	[[Category:worlddevelopment]]

← Abfassung vorher		Version vom 18. Juni 2017, 11:50 Uhr
Zeile 58:		Zeile 58:


−	* ~~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)~~	+	* fetching, inspecting the sources of a project in a certain version is still possible but it does not provide the full repository contents in general. Patches can still be derived though after e.g. debugging or further developing this certain version. The rebase later on can result in conflicts that need be resolved.

@@ Zeile 6: / Zeile 6: @@
 ===Platform and content independent dependency resolution===
 * For releases: 0install reads the feed to resolve dependencies, downloads, installs them and creates read-only links.
-* For development: Manually or 0install triggered download of the repository (clone, pull which is fetch + merge). Git post merge hook triggers: The contained 0install feed is parsed, dependencies downloaded, installed, read-only links created (to prevent accidental override, which encourages single source principle, i.e. change it upstream where the link points to. This makes it easy to generate a patch and submit it at the origin of the dependency).
+* For development: Manual or 0install triggered (not yet) download of the repository (clone, pull which is fetch + merge). Git post merge hook triggers: The contained 0install feed is parsed, dependencies downloaded, installed, read-only links created (to prevent accidental override, which encourages single source principle, i.e. change it upstream where the link points to. This makes it easy to generate a patch and submit it at the origin of the dependency).
 New dependencies are set up manually by developers first (linked, used in the project, tested) and then added to the feed.

@@ Zeile 1: / Zeile 1: @@
 ==Why==
-install is used as cross-platform dependency resolver for not having to package the projects' releases for multiple package managers.
+* No need to package the projects' releases for multiple package managers.
 * easier finding of projects for forking / referencing by potential developers
 * potentially reducing redundancy or at least structuring it better because related projects are referenced automatically.
@@ Zeile 12: / Zeile 38: @@
-* version control.
+* depending on modules in any revision range (unlike Git submodules which was used for providing modularity prior to 0install and only allows to depend on one and only one commit, i.e. a single version instead of a range)
 * which may be distributed using any version control or package management system (not necessarily 0install which is just a convention that e.g. worlddevelopment uses)
 * what allows depending on almost all open source projects already developed.

@@ Zeile 63: / Zeile 63: @@
 ==How to package==
-It is recommended to use 0repo. The exact procedure is currently undocumented. An easy example to start with is [http://github.com/farietree/freecad_convert freecad_convert]. Key is to understand the [http://0install.net/tools.html 0install tools].
+It is recommended to use 0repo. The exact procedure is currently undocumented. An easy example to start with is [http://github.com/faerietree/freecad_convert freecad_convert]. Key is to understand the [http://0install.net/tools.html 0install tools].
 A module package version is released directly in the Git repository. See 0install, git interaction outlined under [[#Why]].

← Abfassung vorher		Version vom 1. Januar 2017, 21:13 Uhr
Zeile 63:		Zeile 63:

	==How to package==		==How to package==
		+	It is recommended to use 0repo. The exact procedure is currently undocumented. An easy example to start with is [http://github.com/farietree/freecad_convert freecad_convert]. Key is to understand the [http://0install.net/tools.html 0install tools].
		+
	A module package version is released directly in the Git repository. See 0install, git interaction outlined under [[#Why]].		A module package version is released directly in the Git repository. See 0install, git interaction outlined under [[#Why]].