Commits

Herbert Breunung  committed 8256cb5 Merge

dunno what I do :)

  • Participants
  • Parent commits 1062711, 5467c3b
  • Branches sp3

Comments (0)

Files changed (2)

File doc/CompleteProgramming.pod

 =head1 Complete Programming
 
-This document describes the method the Kephra editor is developed with.
-Its highest aim is to have at all times a usable program with the
-highest quality at all levels while still letting programming be fun.
+    This document describes the method the Kephra editor is developed with.
+    Its highest aim is to have at all times a usable program with the
+    highest quality at all levels while still allowing programming be fun.
+
 
 
 =head2 Overview
 
 =head3 DISCLAIMER
 
-I strongly dislike strict rules imposed on me and made fun of people that
-produce theories with three letter acronyms that try to be the answer to everything.
-But now I am standing here, trying to "sell" you yet another programming methodology.
-That IS irony, isn't it?
+    The name is a reminder that we reach for the impossible,
+    because software is never complete. So please focus AND relax.
 
-=head2 Rational
+    I strongly dislike strict rules imposed on me and make fun of people that
+    produce theories with three letter acronyms that try to be the answer to everything.
+    But now I am standing here, trying to "sell" you yet another programming methodology.
+    That IS irony, isn't it? At least I use only two letters beause this is more important.
 
-Well, several reasons brought me here.
+=head3 Intentions
 
-1.) All methodologies I know of overlook several aspects of the product.
-    That includes even "documentation driven development",
-    which gave important impulses for the creation of CP.
+    Well, several reasons brought me here.
 
-2.) I always wanted a sane balance between the old bureaucratic waterfall method
-    and a bit too shortsighted, modern extreme or agile programming, combining
-    sound planning and practicability.
+    1) I always wanted a sane balance between the old bureaucratic waterfall method,
+       and the modern extreme or agile programming, which is a bit too shortsighted,
+       and accumulates additional work as the project grows.
+       It should be possible to combine sound planning, practicability and quick results.
 
-=head2 Main Goal
+    2) Writing tests is no silver bullet and is used for several competing purposes.
 
-Highest aim is the conscience the code is produced with. A superb overall
-user experience as well as good code quality should be result of it. 
+    3) The awesome powers of prototypes are still not fully used.
 
+    4) All methodologies I know of overlook several aspects of the product.
+       That includes even "documentation driven development",
+       which gave important impulses for the creation of CP.
 
-=head2 Phases of Development
+    5) New tools like hg or git allow new workflows which solve pending problems.
 
-Even if productive software is never done and you wand to get something usefull
 
+=head3 Main Goal
 
-=head3 Defining Task
+    Highest aim of CP is the conscience the code is produced with. As result you get
+    
+=item a superb overall user experience
+=item quality code
+=item transparent project planning and status
+=item room for experiments and changes without trouble
 
-main task
+
+=head3 Principles
+
+=item Every action has a productive and lasting (yet changable) result.
+=item All code, data and metadata of the project go into one repository.
+=item Before implenenting a functionality that isn't just a lib call write a prototype.
+=item Before implementing a use case, write a prototype.
+=item These two types of prototypes stay in their respective dir/branch.
+=item After the prototype you write the docs, then the code and then the test. 
+=item When implementing a feature, do also the docs, test, GUI and the configs.
+
+
+
+=head2 Details
+
+
+=head3 Planning
 
 aprox. feature set
+what kind of team to solve it with
+resources
 
-parts to do
+what technologies, languages, libs, os, other tools
+fallback alternatives or areas you might expand into
+
+
+=head3 Prototypes
+
+=head3 Documentation
+
+=head3 Code
+
+=head3 Tests
+
+=head3 Completeness
+
    * documentation (user, programmer, comments)
    * prototypes
    * supply libs 
    * visuals
    * configs
 
-resources
+=head3 Releases
 
-what kind of team to solve it with
 
-what technologies, languages, libs, os, other tools
-fallback alternatives or areas you might expand into
 
-=head3 Early Development
-
-=head3 Normal Development
-
-=head3 Maintenance
-
-
+parts to do
 
 =over 4
-=item * 
 =back

File lib/Kephra/Versioning.pod

 
 =over 2
 
-=item * simple (as linear as possible - as a watch)
+=item * simple (linear as a watch)
 
 =item * measures development status not time
 
 If one number is raised, all to the left get a reset to zero.
 Trailing zeros can be omited - 0.5 is the same as 0.5.0.0
 
+Some similar idea is known as semantic versioning L<http://semver.org>.
+
 =head3 Development
 
 Development number is changed after every important commit.
 =head2 What Changed?
 
 We dropped the special patchlevel number.
-The version 0.3 Patchlevel 5 is now 0.3.0.5.
+The version 0.3 Patchlevel 5 is now 0.3.0.5.