-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Kevin Day wrote: > > And then, when all these goals are reached, mark it as stable. > The version will be stable for the exact > versions/patches/desired_features(like SSP) done. > And no matter what happens, never upgrade anything past the goal or > add anything
Hm, I'd beg to differ. My suggestion: define what is meant by "stable" and define a set of test criteria that, when passed, indicate stability. Create a development, test (aka release candidate) and stable (aka release) branch. (Well, strictly speaking, I'd make dev the trunk and test and stable the branches.) - - Let dev change according to perceived need of the HLFS community. - - Promote to test when dev leaders believe they have a stable build. This is a feature freeze. Run the unit/system tests until stability is proven. Make fixes in this branch (and backport to dev as needed) until the tests pass. - - Promote builds that pass the test suite to the stable branch. For example, I'm using svn-20060510 quite successfully (in a small-scale production environment); I'd use that as the basis for the test branch and the current build as the basis for dev. - -jps -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFCtye/58LuvnbUSQRAvtjAJ9eCId2/FkilFmJTKTbv0Gt8uabJQCggcHy dlg7MTx2X+FgGFzYhNdwzho= =m14o -----END PGP SIGNATURE----- -- http://linuxfromscratch.org/mailman/listinfo/hlfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
