--- a/devel-ideal-proj.rst Sun Oct 23 20:21:29 2011 +0300
+++ /dev/null Thu Jan 01 00:00:00 1970 +0000
@@ -1,82 +0,0 @@
--*- mode: outline; coding: utf-8; -*-
-
-* Ideal software development model.
-
-This file mainly discuss about open source software project.
-
-* Open source.
-
-Open source software project have freedom how develop project and which
-development toolchains use.
-
-* Close source.
-
-Close source projects have proprietary nature because of:
-
- * interest to make money (another parties can not easily reproduce project or
- steal realisation ideas/code, allowing another party get same product and get
- company money)
- * low code quality (to stop stain company good name or to stop malicious
- attacks based on code analysis)
- * security consideration (to hide protocols and data format to make harder
- malicious attack)
- * business model (closed data formats allow vendor lock)
-
-Disadvantage of closed source project (in many case):
-
- * you can not directly contact with developers (only through support)
- * low support quality
- * paid support (and you have no enough money)
- * can not access to product bug tracing system (you only can submit bug via
- crash report application or technical support, publicly appear internal bug
- tracing can damage product reputation
-
-* Component of software project.
-
- * Src (sources).
- * Doc (documentation).
- * VCS (version control system).
- * BTS (bug tracking).
- * News (project news/history/changelog).
-
-* Docs.
-
-TODO
-
-* Project home page.
-
-Project home page must provide:
-
- * project name
- * short info about project goal
- * project license
- * current project status
- * links to binary release
- * links to source release, how to get latest source from VCS
- * links to online/printed docs
- * how report bug (BUGS)
- * where send patch
- * contact info
-
-Additionally:
-
- * help welcome, requirement to join to project
- * mail/news list for users/developers, how to subscribe/unsubscribe, where
- find archive, how search for keyword in archive
- * project history (NEWS, ChangeLog)
- * project policy (HACKING)
- * how build project (README, INSTALL)
- * list of contributor with contact info (MAINTAINERS, AUTHORS)
- * who use project
-
-* VCS.
-
-TAGS: VCS, version control system, SCM, source code management, DVCS,
- distributed version control system.
-
- * CVS
- * SVN
- * Mercurial (hg)
- * git
- * bazaar
-
--- a/devel-productivity.rst Sun Oct 23 20:21:29 2011 +0300
+++ /dev/null Thu Jan 01 00:00:00 1970 +0000
@@ -1,10 +0,0 @@
--*- mode: outline; coding: utf-8; -*-
-
-* Productivity statistic.
-
-KLOC (kilo lines of code), MM (man month).
-
-41 KLOC / 119 MM == 11 LOC/day | 5 people | hard task, high/middle skills, new to domain
-6 KLOC / 24 MM == 8.3 LOC/day | 6 people | hard task, high skills
-26 KLOC / 46 MM == 19 LOC/day | 7 people | easy task, middle skills
-155 KLOC / 20 MM == 260 LOC/day | 7 people | middle task, high skills, high level programming
--- a/devel-proj-branching.rst Sun Oct 23 20:21:29 2011 +0300
+++ b/devel-proj-branching.rst Mon Oct 24 09:59:06 2011 +0300
@@ -16,12 +16,12 @@
* For development on initial project stage.
* Does not for experimental features!
-Names: dev, devel, master, trunk
+Names: dev, devel, master, trunk, default
Feature branch.
---------------
- * For experimental features.
+ * For experimental features, that can be striped.
* For large changes that can break main development.
* For incompatable changes that can break main development.
@@ -37,7 +37,19 @@
from release manager after reviewing code quality by QA team.
* From release branch you make tags to product releases for customer.
-Names: vXX.YY.ZZ, maint
+Names: vXX.YY.ZZ, maint, stable
+
+Custom branches.
+----------------
+
+Custom branches intended to store modification to main release to make custom
+product build.
+
+Don't use custom branches at all. Instead redesign project to use customizable
+build. Expected problem:
+
+ * You must manually propagate bug fixed to all custom branches.
+ * It is not possible merge custom branches back to development branch.
Workflows.
==========
@@ -58,3 +70,81 @@
TODO
+Single line workflow.
+---------------------
+
+ * Only single development branch exist.
+ * Release means finish developing set of features and bug fixes on branches and
+ moving product build to release server..
+ * After testing and stabilising release was made. This means:
+
+ * VERSION file was updated.
+ * CHANGE file was filled with feature set, version, data and VCS revision
+ number.
+ * Mark release by tag in VCS.
+ * Invoke build of sources which marked by tag. Copy result to release server.
+
+ * If bug discovered in some version, it fixed at development branch and
+ released with new minor/fix product version.
+ * Previous major/minor releases do not supported (just use latest release).
+ Users always forced to update to latest release.
+ * Each new release placed in hierarchy::
+
+ /vendor/product/XX.YY.ZZ/*
+
+ and symlinked to::
+
+ /vendor/product/latest/
+
+Example of release timeline::
+
+ +--+------+------+------+------+------+------+------+------+---->
+ dev| | | | | | | | |
+ v v v v v v v v v
+ t0.1.0 t1.0.0 t1.0.1 t1.1.0 t1.1.1 t1.1.2 t1.2.0 t2.0.0 t2.1.0
+
+Single development branch with branches for bug fix in major versions.
+----------------------------------------------------------------------
+
+ * Each major release have **own** branch.
+ * Another single branch reserved for development.
+ * Latest major relase branch is active. All older major branches is passive.
+ * Passive major branches was used for **only** for minor bug fixes on latest
+ code from this major version series (no new features).
+ * Features developed in development branch. Before release in merged to active
+ major release branch.
+ * Bug was fixed in oldest major version branch for which it must be provided
+ and merged to all next major version branches and development branch.
+ * Release means finish developing set of features and bug fixes on branches and
+ moving product build to release server..
+ * After testing and stabilising release was made. This means:
+
+ * VERSION file was updated.
+ * CHANGE file was filled with feature set, version, data and VCS revision
+ number.
+ * Mark release by tag in VCS.
+ * Invoke build of sources which marked by tag. Copy result to release server.
+
+ * If bug discovered in some version, it fixed at development branch and
+ released with new minor/fix product version.
+ * Previous major/minor releases do not supported (just use latest release).
+ Users always forced to update to latest release.
+
+Example of release timeline::
+
+ +--+-----+----------------------+-----+----+------+------+----->
+ dev| | ^ ^ | | | | |
+ | | | | | | v v v
+ | | | | | | +--+------+------+-->
+ | | | | | | b2 | | |
+ | | | | | | v v v
+ | | | | | | t2.0.0 t2.0.1 t2.1.0
+ v v | | v v
+ t0.1.0 +---+------+-+---+-+-----+------+------+------+------+--->
+ b1 | | | | | | | |
+ v v v v v v v v
+ t1.0.0 t1.0.1 t1.0.2 t1.1.0 t1.2.0 t1.2.1 t1.2.2 t1.2.3
+
+In this example we release tags **1.0.1** and **1.0.2** with bug fixes in branch
+**1** as development branch was not ready for production.
+
--- a/devel-proj-files.rst Sun Oct 23 20:21:29 2011 +0300
+++ b/devel-proj-files.rst Mon Oct 24 09:59:06 2011 +0300
@@ -358,9 +358,12 @@
Todo files.
===========
- * list of wanted, roadmap
+ * List of high level wanted, general project roadmap.
+ * Discussion about product limitations and how to modify product to resolve
+ them.
-::
+Similar::
+
BACKLOG
CHECKLIST
TODO
--- a/devel-versioning.rst Sun Oct 23 20:21:29 2011 +0300
+++ b/devel-versioning.rst Mon Oct 24 09:59:06 2011 +0300
@@ -71,6 +71,9 @@
Prefixing version with a "v" seems to be less common.
+Versioning for libraries/modules/components.
+============================================
+
Major version component.
------------------------
@@ -112,12 +115,38 @@
* rc (release candidate) are believed to meet all of the criteria for release
and can be installed on test instances of production systems.
+Versioning for products.
+========================
+
+Versioning for products differ from versioning for libraries.
+
+Product is a set of conponents fixed to some versions. Components can be
+switches as written for library versioning:
+
+ * Any fix release interchanged.
+ * Any minor release interchanged starting from some minor.
+ * Major release does not interchanged at all.
+
+Product update vs upgrade.
+--------------------------
+
+Product update involve:
+
+ * Replacing product executable files, resources files.
+ * Config files and user data stay unchanged.
+
+Product update involve:
+
+ * Replacing product executable files, resources files.
+ * Config files and used data require modification and performed by upgrade
+ scripts or manually by user.
+
Release build version data.
===========================
* Build number.
* Build date.
- * Build version.
+ * VCS revision.
* Branch-tag used.
* Overnight build (Y/N).
* QA tested (Y/N).
@@ -161,14 +190,15 @@
Semver version ordering formula.
--------------------------------
+::
-if (A.major != B.major) return A.major > B.major;
-if (A.minor != B.minor) return A.minor > B.minor;
-if (A.patch != B.patch) return A.patch > B.patch;
-if (A.special == B.special) return 0;
-if (A.special == "") return 1;
-if (B.special == "") return -1;
-return A.special > B.special;
+ if (A.major != B.major) return A.major > B.major;
+ if (A.minor != B.minor) return A.minor > B.minor;
+ if (A.patch != B.patch) return A.patch > B.patch;
+ if (A.special == B.special) return 0;
+ if (A.special == "") return 1;
+ if (B.special == "") return -1;
+ return A.special > B.special;
**NOTE** Accoding to this definition 1.0.1rc1 < 1.0.1rc10 < 1.0.1rc2 which is
non meaningful.
--- a/firefox.rst Sun Oct 23 20:21:29 2011 +0300
+++ b/firefox.rst Mon Oct 24 09:59:06 2011 +0300
@@ -70,8 +70,8 @@
========================================
::
-Preference -> Content -> JavaScript ->
- Advanced -> disable "Move and resize existing windows"
+ Preference -> Content -> JavaScript ->
+ Advanced -> disable "Move and resize existing windows"
How limit simultaneously connection counts?
===========================================
@@ -79,7 +79,7 @@
network.http.max-connections - 4
-or search by word `connections' in "about:config".
+or search by word 'connections' in 'about:config'.
See:
--- a/x.rst Sun Oct 23 20:21:29 2011 +0300
+++ b/x.rst Mon Oct 24 09:59:06 2011 +0300
@@ -91,7 +91,7 @@
hierarchy. A colon (:) is used to separate the resource
declaration from the actual value.
-Comment start with '!' char and goes up to end of line or C-like /* */.
+Comment start with '!' char and goes up to end of line or C-like ``/* */``.
Use xprop utility to find classes and resources used by application.