kc3-lang/automake/PLANS/README

Branch - branch -masterv1.18- tag -v1.18.1v1.17.92v1.17.90v1.17v1.16iv1.16.92v1.16.90v1.16.5v1.16.4v1.16.3v1.16.2v1.16.1v1.16v1.15.1v1.15v1.14.1v1.14v1.13bv1.13.4v1.13.3v1.13.2bv1.13.2v1.13.1dv1.13.1bv1.13.1v1.13v1.12bv1.12.6v1.12.5v1.12.4v1.12.3v1.12.2v1.12.1v1.12.0bv1.12v1.11dv1.11bv1.11v1.10buser-dep-gen-branchpointpre-ian-conditionalspre-depend-changeng-0.5amerging-into-user-dep-genlast-merge-into-user-dep-gen-branchhandle-languagesbranchpoint-real-1-5branchpoint-1-9branchpoint-1-8branchpoint-1-7branchpoint-1-6branchpoint-1-5branchpoint-1-10Release-1-9bRelease-1-9Release-1-8dRelease-1-8bRelease-1-8Release-1-7hRelease-1-7fRelease-1-7dRelease-1-7bRelease-1-7-3bRelease-1-7-2bRelease-1-7Release-1-6fRelease-1-6dRelease-1-6bRelease-1-6-1bRelease-1-6Release-1-5dRelease-1-5bRelease-1-4jRelease-1-4hRelease-1-4fRelease-1-4dRelease-1-4bRelease-1-4Release-1-3dRelease-1-3bRelease-1-3Release-1-2hRelease-1-2gRelease-1-2eRelease-1-2dRelease-1-2cRelease-1-2bRelease-1-2Release-1-1pRelease-1-1oRelease-1-1mRelease-1-1lRelease-1-1kRelease-1-1iRelease-1-1hRelease-1-1gRelease-1-1fRelease-1-1eRelease-1-1dRelease-1-1cRelease-1-1bRelease-1-1aRelease-1-10Release-1-0Release-0-33Release-0-32Release-0-31Release-0-30Release-0-29Release-0-28Release-0-27Release-0-26Release-0-25

• Show log

  Commit

• Hash : c2757b97
  Author :
  Date : 2017-09-19T13:43:07
  

  maint: Reset master
  

Download

• PLANS/README

• "Plans" for future or on-going Automake development.
  
  The contents is meant to help ensure a more controlled and smooth
  development and evolution for Automake, in several ways.
  
   - Having the plans clearly spelled out should will avoid messy
     roadmaps with no clear way forward or with muddy or ill-defined
     aims or purposes; a trap this is too easy to fall into.
  
   - Keeping planned changes cooking and re-hashed for a while should
     ensure rough edges are smoothed up, transitions are planned in a
     proper way (hopefully avoiding debacles like the AM_MKDIR_PROG_P
     deprecation and the AM_CONFIG_HEADER too-abrupt removal), and
     "power users" have more chances of getting informed in due time,
     thus having all the time to prepare for the changes or raise
     objections against them.
  
   - Having the plans clearly stated and registered in a "centralized"
     location should make it more difficult to them to slip through
     the cracks, getting forgotten or (worse) only half-implemented.
  
   - Even for discussions and plans registered on the Bug Tracker
     as well, a corresponding entry in the PLANS directory can help
     in keeping main ideas summarized, and consensus and/or objections
     registered and easily compared.
  

Download