# HG changeset patch # User Oleksandr Gavenko # Date 1319439546 -10800 # Node ID fdc5ed189bd330d231fc94050d362ab03e6bcfc6 # Parent 409aab81f81828c2cb56fc267fc4209db9ade04e# Parent 4c3c9b4f8d7362123eabdec768f19980bae65db9 merge diff -r 409aab81f818 -r fdc5ed189bd3 devel-ideal-proj.rst --- 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 - diff -r 409aab81f818 -r fdc5ed189bd3 devel-productivity.rst --- 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 diff -r 409aab81f818 -r fdc5ed189bd3 devel-proj-branching.rst --- 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. + diff -r 409aab81f818 -r fdc5ed189bd3 devel-proj-files.rst --- 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 diff -r 409aab81f818 -r fdc5ed189bd3 devel-versioning.rst --- 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. diff -r 409aab81f818 -r fdc5ed189bd3 firefox.rst --- 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: diff -r 409aab81f818 -r fdc5ed189bd3 x.rst --- 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.